AUERBACH 


Guide to 
Operating System 
Enhancements 



AUERBACH 
















AUERBACH COMPUTER TECHNOLOGY REPORTS 

AUERBACH Computer Technology Reports (ACTR) is the primary source for worldwide information on EDP equipment 
and its evaluation and selection. An encyclopedic data base, ACTR is also a totally flexible, easy-to-use repository of 
up-to-date analyses, evaluations, and technical insights. ACTR provides EDP professionals with the answers to today’s 
technological problems today. It offers opportunities for professional growth, increased savings, current awareness, and 
sharing the experiences of others. For all major products AUERBACH provides a concise overview, objective discussion 
of relation to competitors, user reactions, equipment compatibility, technical details, vendor maintenance capabilities, 
and pricing information. 

ACTR features monthly revised reports, updates to existing reports, and new reports on the latest products. The most 
significant announcements are covered by HOTLINE reports, an AUERBACH exclusive that gets the analyses to the 
reader in the shortest time. The Subscribers Newsletter keeps you current on the complete AUERBACH data base, while 
the monthly AUERBACH Reporter discusses major EDP industry happenings. “Ask AUERBACH” by telephone, and the 
editorial research staff will give you the answers immediately, at no charge. 

AUERBACH Computer Technology Reports cover the following major industry segments: 

^ GENERAL-PURPOSE COMPUTER SYSTEMS. IBM 370/125 or the equivalent & above. 

► SMALL BUSINESS SYSTEMS. Small business computers; small business computer software; office computers; 

intelligent terminals. 

► MINICOMPUTERS. Process control systems; microcomputers; general-purpose minicomputers; minicomputer 

peripherals. 

► STANDARD PERIPHERALS. On-line card equipment; high-speed printers; on-line paper tape equipment; extended 

core & replacement memory; magnetic tape systems; disc systems. 

► DATA HANDLING SYSTEMS. Card preparation & handling; paper tape preparation & handling; key-to-storage; OCR 

& Mark Sense; multi-media data entry systems; magnetic ink character recognition; credit authorization; point- 
of-sale system; industrial data collection; multi-purpose data collection; financial terminal system; word 
processing; office copiers; digital plotters; automatic photocomposers. 

► MICROFORM SYSTEMS. COM & CIM; readers/printers, retrieval systems, cameras; processors; duplicators. 

► APPLICATIONS SOFTWARE. Payroll; accounts receivable; accounts payable; general ledger; general accounting; 

general manufacturing; inventory control; banking; financial/accounting; insurance; law; manufacturing; per¬ 
sonnel; project control; transportation. 

► SYSTEM SOFTWARE. Operating systems; operating system enhancements; data communications control; com¬ 

pilers; data base management; assemblers; translators; precompilers & program generators; documentation 
aids; test file generators; information storage & retrieval; report generators; graphics; performance evaluators; 
system simulators; librarians. 

► DATA COMMUNICATIONS EQUIPMENT. System design; common-carrier facilities; communication processing 

equipment; multiplexors; modems; communications test equipment. 

► COMPUTER TERMINALS. Teleprinters; A/N displays; remote batch terminals; intelligent terminals; audio response 

systems; facsimile equipment. 

► TIME SHARING. 

The unique structure of the ACTR data base allows our subscribers to obtain periodically updated information on the 
preceding categories through any combination of the following subscription products: 

• AUERBACH CORPORATE EDP LIBRARY (C600). Covers all of the categories listed. 19 binders; updated monthly 

• AUERBACH STANDARD EDP REPORTS. General-purpose computer systems, small business systems, standard pe¬ 

ripherals, system software. Nine binders; updated monthly 

• AUERBACH MINICOMPUTER REPORTS. Small business systems and minicomputers. Three binders; updated monthly 

• AUERBACH INPUT/OUTPUT REPORTS. Standard peripherals, data handling systems, and microform. Three binders; 

updated monthly 

• AUERBACH MICROFORM REPORTS. Microform. One binder; updated monthly 

• AUERBACH SOFTWARE REPORTS. Applications software and system software. Two binders; updated monthly 

• AUERBACH DATA COMMUNICATIONS REPORTS. Data communications equipment and computer terminals. Three 

binders; updated monthly 

• AUERBACH TIME SHARING REPORTS. Commercial time sharing services. One binder; updated bi-monthly 

• AUERBACH EDP NOTEBOOK. Reports selected from the 18-volume AUERBACH Corporate EDP Library. Selection is 

based on systems of most interest to the EDP community in the areas of computer systems, terminals, peripherals, 
data entry, and system software. Four binders; updated monthly 

• AUERBACH DATA COMMUNICATIONS NOTEBOOK. Reports selected from the three-volume AUERBACH Data Com¬ 

munications Reports. One binder; updated monthly 

• AUERBACH MINICOMPUTER NOTEBOOK. Reports selected from the three-volume AUERBACH Minicomputer Reports. 

Two binders; updated monthly 

• AUERBACH SPECIAL SERVICE (C650). This two-volume service consists of reports extracted from the nine-volume 

AUERBACH Standard EDP Reports. One volume consists of selections from reports on the most active general- 
purpose computer systems in today’s international marketplace; the other volume covers all the detailed analyses 
of system software available from the mainframe vendors and independents. Two binders; updated monthly 

• AUERBACH SPECIAL SERVICE (C660). Complete applications software coverage. One binder; updated monthly 

• AUERBACH SPECIAL SERVICE (C665). Complete system software coverage. One binder; updated monthly 

• AUERBACH SPECIAL SERVICE (C670). All standard peripherals and data handling systems coverage. Two binders; 

updated monthly 


(c) 1976 AUERBACH Publishers Inc. 


PRINTED IN U.S.Al 


*fV \J76 











i'/ '(>/ /Lr-^LM 



AUERBACH 


Guide to 

Operating System 
Enhancements 


The material contained In this publication is In¬ 
cluded in AUERBACH Computer Technology Reports, 
an analytic reference service that provides compre¬ 
hensive coverage of the information processing 
industry. 

^ I 



AUERBACH 


Publishers Inc. 
phi ladel phia 
penna.19107 



Standard Book Number 0-87769-219-X 
Library of Congress Card Number 75-37935 
Printed in the United States of America 
Copyright © 1975 by AUERBACH Publishers Inc. 
121 North Broad Street 
Philadelphia PA 19107 
All Rights Reserved 


The information contained herein has been obtained from reliable 
sources and has been evaluated by experienced technical personnel. 
Due to the rapidly changing nature of the technology and equip¬ 
ment, however , the information cannot be guaranteed. 


All rights reserved No part of this work 
covered by the copyrights hereon may 
be reproduced or used in any form or 
by any means-graphic, electronic, or 
mechanical, including photocopying, re¬ 
cording, taping, or information storage 
and retrieval sy st e m s-w it h out written 
permission of the publisher. 


Published by AUERBACH Publishers Inc., 121 N. Broad Street, Philadelphia PA 19107 

I 


Printed in the United States of America 





CONTENTS 


Page 

PREFACE iii 

PACKAGE REPORTS 

ADL Systems (IP/ISAM) 1 

Applied Data Research (PiSort 2) 3 

BMS Computer (DOSRELO) 5 

BMS Computer (Spooler) 7 

Comress (Amigos) 9 

Cutler-Williams (Executor) 11 

Grumman Data Systems (COPS) 13 

Gulf Oil Computer Sciences (UCANDU) 15 

Innovation Data Processing (Fast Dump Restore) 17 

Marcus Powell Associates (Anyplace II) 19 

Marcus Powell Associates (CATALR) 21 

Oxford Software (Dynamic File Allocation System DFAST) 23 

Oxford Software (Sprint) 25 

Pansophic Systems (PAN-DA) 29 

Pansophic Systems (Pan-Sort) 33 

Programart Corporation (Disclose) 35 

Rockwell International Corporation (Restart) 39 

Software Design (FMAINT) 41 

Software Design (GRASP) 43 

Software Des i g n (G RAS PVS) 47 

Standard Data Corporation (VM/370 ISAM) 51 

Standard Data Corporation (VSORT) 53 

Subsystems Inc. (Easyreader) 55 

Tesdata Systems (Deadline II) 57 

Tesdata Systems (Streamline) 61 

Tesseract (Data Access Security System — DAS) 65 

Universal Software (AVR-Plus) 67 

Universal Software (DOS ASAP) 69 

University Computing (UCC Two) 71 

University Computing (UCC Fifteen) 73 

Value Computing (System III and Data Center Scheduler) 75 

Weiland Computer Group (VISAM) 79 

Westinghouse (Virtual Disk Utility and Dump/Restore/Plus Programs) 83 
Whitlow Computer Systems (SyncSort III) 85 

DIRECTORY OF SUPPLIERS 89 


i 




r 


L 


PREFACE 


If you really think about it, nothing plays a more vital role in the suc¬ 
cess or failure of a computer than its operating system. This piece of 
software essentially replaces human intervention and interaction with 
the hardware when it comes to scheduling jobs, allocating resources, 
controlling data storage and accessing, and sorting data into usable in¬ 
formation. Any weak spots in the operating system show up very quickly, 
as the cries of users will attest. 

But, like humans, operating systems have their shortcomings. The job 
scheduling and resource allocation techniques, for example, may be too 
rigid or sophisticated to be truly effective in the “real” world. Or the data 
storage and accessing techniques may be grossly inefficient. Regard¬ 
less of the cause of the shortcoming, the effect is waste—in both man¬ 
power effort and system resources. This adds up to lots of money down 
the drain. 

Smart entrepreneurs recognized this problem early and began offering 
software alternatives in the form of operating system enhancements. 
These substitutes are faster and more efficient than the parts they re¬ 
place, and more than pay for themselves in increased machine efficiency 
and decreased human frustration. 

The AUERBACH Guide To Operating System Enhancements contains 
a description and evaluation of these “original-equipment” alternatives. 
In it you’ll find better schedulers, I/O techniques, disc and tape utilities, 
sort/merge programs, and even a program that acts as a mini operating 
system. The Guide is enlightening and can save you a lot of money. 

Material included in this Guide has been extracted from the 
AUERBACH Software Reports, a monthly-updated, annual subscription, 
looseleaf reference covering applications and systems software. Infor¬ 
mation included is relatively up-to-date as this Guide is prepared. How¬ 
ever, due to the rapid development of communication technology and 
the price fluctuation typical of this market, users are advised to use this 
Guide as just that, and not as the final authority. For complete and up-to- 
date information on software, refer to the AUERBACH Software Reports. 
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IP/ISAM OPERATING SYSTEM ENHANCEMENTS 


GENERAL 

IP/ISAM is a utility package which interfaces 
between a problem program and IBM’s Index Se¬ 
quential Access Method (ISAM), making this fa¬ 
cility available to all major programming 
languages. 

IP/ISAM runs on any IBM System 360/370 
under OS MFT/MVT. It requires 7K bytes of 
storage for three routines plus core for buffers, 
core indices, work areas, and control block 
tables. The package is written in assembler 
language. 

IP/ISAM’s purchase price is $3000 with dis¬ 
counts for multiple installations. 

The package is available for immediate in¬ 
stallation. IP/ISAM was developed for a partic¬ 
ular ADL client and became operational at that 
installation in mid-1973. 

ADL Systems, Incorporated is the computer 
software subsidiary of Arthur D. Little, Incor¬ 
porated, a management consulting firm. ADL 
Systems offers a spectrum of software-related 
services ranging from systems analysis and de¬ 
sign to ongoing facilities management of large 
computer centers. 

The company provides programming imple¬ 
mentation, testing, and training services, as 
well as a complete range of technical computer 
consultation, feasibility studies, systems plan¬ 
ning, and computer management services. It also 
develops software packages for specialized needs. 

DESCRIPTION 

IP/ISAM enables an application programmer 
to implement all facilities of ISAM without re¬ 
quiring him to have a systems level knowledge of 
ISAM procedures or macro instructions. 

It improves automatic file management and 
simultaneous file access techniques by: 

• Automatically opening and closing ISAM 
files. 

• Guaranteeing file integrity when the same 
ISAM file is updated simultaneously by 
several programs (one copy of IP/ISAM 
can be used to access multiple ISAM files). 

• Switching between sequential (QISAM) and 
random (BIASM) processing modes 
automatically. 


• Reporting all possible error conditions to 
the problem program. 

• Providing statistical information on the 
ISAM file — number of prime and overflow 
records, number of index levels, amount 
of unused overflow space, and so forth — 
making it easy to know when the file needs 
reorganizing. 

IP/ISAM requires the user to define his ISAM 
file using the FCBLK macro. This macro indi¬ 
cates such file attributes as: block size, number 
of overflow tracks, existence of an independent 
overflow area, use of core indices, number of 
I/O buffers, key length, key position, use of data 
integrity feature. Some characteristics of the 
data set (block size, key length, and so forth) 
cannot be changed unless the data set is recre¬ 
ated. Others (use of core index, number of 
buffers, and so forth) can be varied by recalling 
the macro or during program execution. 

Input . Once he has defined the control block 
for the data set to be accessed, the user must 
set up a communications area in his program 
before calling IP/ISAM. This interface area 
identifies the data set and specifies record 
length, error code, key area, and record buffer. 
Table 1 summarizes the techniques available in 
the major programming languages for accom¬ 
plishing the data interface. 


Table 1. IP/ISAM: Interface Techniques 


Language COMMON Definition Parameter List 


Cobol 

No 

Yes 

Fortran 

Yes 

Yes 

PL/1 

Yes 

Yes 

Assembler 

Yes 

Yes 

RPG 

No 

Yes 


To execute IP/ISAM the user must also supply 
two JCL cards which enable the OS supervisor to 
logically associate the file described in the con¬ 
trol tables with the proper ISAM file. 

Process . Three assembler-language routines 
handle the actual ISAM access requests made by 
the user programs. These routines are 
ISAMROOT, ISAMPREP, and ISAMACTN. 

ISAMROOT contains all function entry points, 
and all static work areas required by EP/ISAM. 
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It must always be explicitly link-edited with the 
user’s program. 

ISAMPREP executes certain preparatory ac¬ 
tions before the actual requested I/O function is 
executed. It will, for example, ensure that the 
appropriate data control blocks are correctly es¬ 
tablished for the requested function. 

ISAMACTN performs the actual data set ac¬ 
cess function, as requested by the user. 

IP/ISAM has several entry points, each cor¬ 
responding to a unique data set access. Depend¬ 
ing on the call, the user may: 

• Write a record to the file while it is being 
created. 

• Add a record to the file after it has been 
created. 

• Change a record already existing in the file 
(random access). 

• Delete a record from the file. 

• Change a record already existing in the 
file (sequential access). 

• Append a record to the end of a file. 

• Read a record from a file (random access). 

• Initiate sequential retrieval on a file. 

• Continue sequential retrieval on a file. 

• Dynamically modify certain file processing 
attributes. 

• Terminate processing a file. 

Output . If execution has been accomplished 
successfully, IP/ISAM lists statistical data de¬ 
scribing the file (number of overflow records, 
number of cylinders used, and so forth). Other¬ 
wise, the error indicator in the communications 
area will contain an error code explaining why ex¬ 
ecution failed. 

Evaluation . Because the package is in use at 
only one installation, we can't really verify the 
accuracy of the vendor’s claim that development 


time for a data processing project can be cut 10 
to 15 percent. However, the one user we spoke 
to did find that use of core indices for process¬ 
ing a data set in BIASM mode significantly im¬ 
proved performance. In addition, he found that 
IP/ISAM, because of its ease of use, fosters ex¬ 
tensive use of ISAM in applications where it pre¬ 
viously was "programmed around." This user is 
quite pleased with the package’s performance and 
the increased use of ISAM it developed in his 
shop. 

For all practical purposes, IP/ISAM can pro¬ 
cess a virtually unlimited number of ISAM files 
simultaneously. Available core storage is the 
factor which limits the number of files processed 
at the same time. 

IP/ISAM is a unique package, bringing ISAM 
performance capabilities to every programmer 
in every programming language. IP/ISAM might 
be the answer to any data processing shop re¬ 
luctant to use or having problems with ISAM. 
Because it requires only a familiarity with calling 
sequences or data transferrin a programming lan¬ 
guage, IP/ISAM could provide the basis for es¬ 
tablishing an installation-wide standard for ISAM 
data set management and accessing regardless of 
the programming language or ISAM experience at 
the applications level. 

SUPPORT 

The user receives the IP/ISAM in magnetic tape 
or object deck form for installation himself. He 
also receives a user’s manual containing installa¬ 
tion and operation instructions, along with de¬ 
scriptions of the package, ISAM, and interface 
definitions. On request ADL will install the pack¬ 
age and train user personnel on a time and mate¬ 
rials basis. 

ADL maintains the system for one year, 
supplying versions of IP/ISAM compatible with 
new releases of the operating system. There¬ 
after, maintenance is available for a $500 yearly 
fee. 

HEADQUARTERS 

ADL Systems, Incorporated 

25 Acorn Park 

Cambridge MA 02140 
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OPERATING SYSTEM ENHANCEMENTS 


OVERVIEW 

PiSort 2 is a self-relocating disc sort program for files 
with fixed length, blocked, or unblocked records. It is pur¬ 
ported to operate in less time and with less working space 
than IBM’s sort 483. 

PiSort 2 runs on any IBM System/360 or 370 model 
under DOS or DOS/VS with at least 32K and one 2311 
disc, or at least 65K and one 2314, 3330, or 3340 disc. 
Partition requirements are a minimum of 20K for 231 Is 
as intermediate storage, 30K for 2314s, 48K for 3330s, 
and 32K for 3340s. PiSort 2 is a single program with mul¬ 
tiple overlays, written in BAL. 

The package can be leased for $100 a month or perma¬ 
nently licensed for $2,000. 

Introduced in 1970, PiSort 2 is operational in approxi¬ 
mately 150 installations. It has undergone two major 
revisions with extensions added as demand warranted. 

DESCRIPTION 

Functionally compatible with IBM’s sort 483, PiSort 2 
is cataloged into the core image library as an integral part 
of the sorting operation. It does not delete any IBM 
modules but does rename one. The IBM module remains, 
ensuring total backup. Complete control card compati¬ 
bility exists between sort 483 and PiSort 2. 

PiSort 2 sorting algorithm handles fixed length, 
blocked, or unblocked records. 

When PiSort 2 is called on to sort a file which does not 
meet its requirements (or uses any of several other unsup¬ 
ported features — see Evaluation), control is passed auto¬ 
matically to the IBM sort (either 483 or SMI) to handle 
the operation. 

PiSort 2’s processing efficiency is directly proportional 
to the amount of core storage available. It can theoreti¬ 
cally sort a file approximately 20 to 25 percent faster than 
sort 483, depending on the file contents. In many cases, 
the vendor claims, PiSort 2 cuts disc work space in half. 
PiSort 2 is frequently able to sort files too large for Sort to 
handle at one time (i.e., files which sort 483 must divide 
into subfiles, sort, and then merge into the final file). 
Thus, it eliminates merge time and consequent expense. 

PROCESSING 

Input 

Input consists of a series of control cards specifying 
parameters such as input, output, and workfile descrip¬ 
tions; sort controls; and options in effect. The sort opera¬ 
tion is controlled by one to 12 sort keys and can handle as 
many as nine input files in a single operation. 


Process 

As PiSort 2 reads the input file and distributes it on a 
disc workfile, it also performs a statistical study of the file 
sequence. The results of the statistical analysis are input to 
sort models, simulating the sort possibilities, to select the 
most efficient sorting technique. 

The program reads as many blocks as it can into the 
available workspace. If the entire file cannot be read into 
storage, PiSort 2 informs the operator. He can cancel the 
run or he can ignore the message, in which case PiSort 2 
will sort that part of the file in storage. Through this auto¬ 
matic cutoff feature, the entire input file can be sorted into 
pieces, thus eliminating the necessity of restarting the 
application. 

After reading the input file, PiSort 2 performs either a 
single- or multipass sort, based on workspace, core memo¬ 
ry available, and sequence of input data. When enough 
workspace and core memory are available for both tech¬ 
niques, PiSort 2 generally selects the multipass approach, 
which is significantly faster than sort 483. PiSort 2 selects 
the single-pass sort for large files and limited work space. 
In the latter case, sort 483 will abort. 

After PiSort 2 has completed the sort, it performs an 
I/O merge. The resulting file is written to tape or disc. 
PiSort 2 supports spooling printer output to either tape or 
disc; IBM conventions are followed in either case. 

When the PRINT option is used, the listed information 
includes control cards, maximum number of records that 
can be processed in a single- and multipass sort, and total 
tracks available and needed for a given disc type. 

EVALUATION 

In talking with several PiSort 2 users, it becomes obvi¬ 
ous that the vendor’s claims are, in fact, legitimate, al¬ 
though they describe a best-case situation. Users state that 
while PiSort 2 requires less storage than sort 483, it is not 
always as low as half that amount. None of the users inter¬ 
viewed report a 50 percent saving in sort time, although 
all find sort time improved over the IBM requirements — 
between a 23 and 43 percent improvement over sort 483. 
In general, they feel a 50 percent improvement is not an 
unrealistic figure, depending on the characteristics of the 
file to be sorted and the environment in which the sort 
occurs. 

This point takes us to the main problem with the 
package. As far as it goes it performs well, but it seems to 
be designed for the user with an unsophisticated system. 
That is, it sorts only fixed length, sequential files. Anyone 
whose files are the least bit complex will not be able to use 
PiSort 2. In fact, any of the following preclude its use: tape 
workfiles, mixed labels, merge only operations, variable 
length records, COBOL SORT verb, ADDROUT option, 
KEYLEN option, VERIFY option, mixed control field 
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format types, CKPT or CHKPT in SORT statement, 
EXIT on INPFIL or OUTFIL statement, CALCAREA 
option, ALTWK option, BYPASS specified with disc 
input, logical record length greater than 4,096 bytes, and 
overlap of disc output with work area. 


In short, PiSort 2 is not the answer to everyone’s sort 
requirements. However, if it fits one’s needs, it is a definite 
improvement over the IBM alternative. 

SUPPORT 

The lease price includes documentation and mainte¬ 
nance. The user can test PiSort 2 processing for a free, 30- 
day, no-obligation trial period. 


Installation support and formal training of user per¬ 
sonnel by the vendor is unnecessary. 

Documentation consists of a sales brochure and a refer¬ 
ence manual. This manual explains the capabilities of 
PiSort 2 along with operating and installation procedures. 

Package maintenance is included in the rental price. 
Permanent license includes 1 year free maintenance; after 
that, maintenance is optional at $200 per year. Updates 
are supplied at no additional cost. 

HEADQUARTERS 

Applied Data Research, Inc. 

Route 206 Center 
Princeton NJ 08540 
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GENERAL 

DOSRELO is an IBM System/360 or 370 DOS en¬ 
hancement designed to allow user programs and system 
software to automatically relocate and run in any suitable 
partition. The package works with Cobol, PL/1, Fortran, 
assembler, and RPG modules constructed as monolithic 
or multiphase. 

M inimum partition size for DOSRELO is 1 6K bytes on 
either the System/360 or 370. The IBM multiprogram¬ 
ming option is also required. 

Unlike its competitors, DOSRELO does not append 
code to the host supervisor to control relocatability. This 
has the negative effect of prohibiting relocatability of the 
compilers and assemblers used. 

DOSRELO may be purchased (see Table 1) or rented. 
The rental fee is $ 195 a month regardless of the number of 
installations. 

If we were to make a “flack" survey of DOS users, high 
on the gripe list would be nonrelocatability. Simply stated, 
this means that once an object module is designated to run 
in a particular partition, it can’t be relocated to run in 
another. Aside from inconvenience, the lack of a reloca¬ 
tability feature can waste resources and reduce job 
throughput. This is particularly true when a partition of 
suitable size, with acceptable peripherals, becomes avail¬ 
able, but programs in the core image library can’t use it 
because they're not assigned to that area. Thus, the parti¬ 
tion sits empty and the waiting jobs continue to wait. 

To get around this limitation, many users resort to 
redundant cataloging of the same program in the core 
image library. Although this practice does solve the prin¬ 
cipal problem, it also creates a myriad of smaller ones. For 
example, when the supervisor and/or partition size 
changes, recataloging is necessary. Also, redundant 
cataloging requires more disc space and separate JCL. 

Table 1. BMS-DOSRELO: Fees 
Purchase 


Location 

Class A 1 
($) 

Class B 2 
($) 

First 

2,500 

2,500 

Second 

2,000 

2.250 

Third 

1,500 

2,000 

Fourth 

1,000 

1.750 

Fifth 

750 

1,500 

Sixth 

500 

1,250 

Seventh 

500 

1,000 

Each Additional 

500 

500 

Notes: 

1 Class A means 
central location 

BMS provides service through a singl< 

2 Class B means BMS provides service for each location. 


With Release 28 of DOS (called DOS/VS), IBM has 
solved the nonrelocatability problem—along with a 
number of other DOS shortcomings. But DOS/VS is of¬ 
fered free only to System 370/Model 115 through 158 
users, a restriction many believe to be a marketing ploy to 
get System/360 users to trade up to System/370 or to move 
to OS. These “alternatives," however, are unacceptable to 
many users who own, or like, their Models 30, 40, and 50. 
Running OS on anything less than a Model 50 is pure 
folly. 

The most plausible option available to the forgotten 
many is to turn to independently developed packages that 
offer a relocatability feature. Systems such as G RASP and 
EDOS possess it, but only as part of a large sophisticated 
system. Then there are the simple bread-and-butter 
packages like DOSRELO which allow relocation—that’s 
all. 

DESCRIPTION 

DOSRELO, like a few of its competitors, acts as a 
preprocessor to the linkage editor and modifies the con¬ 
tents of the SYSLNK file to make the object modules 
self-relocating. It does so by adding entry point logic in 
front of the program before it’s cataloged in the core 
image library. It also adds a control section to the end of 
the program; this appendage indicates the position and 
size of the address constraints to be relocated. 

At execution time, the problem program is identified 
via an / / EXEC phase statement in the job control 
stream, and control is transferred to the DOSRELO con¬ 
trol section. From there, the offset amount for the 
address constants is determined, as is the actual program 
addresses to the current main memory location. Control 
is then transferred to the user program and execution 
begins. 

Evaluation 

For the most part, DOSRELO is competent enough— 
but it does have some limitations. Whether these are 
problems or just nuisances depends on the setup of the 
evaluating installation. 

For example, all DASD files referenced must be of the 
same type, viz., all 2311s, all 2314s, or all 3330s. This 
restriction can cause some real problems for installations 
using the 231 1 for SYSRES and the 2314 for workfiles. 
Experience has shown this setup to be the rule rather 
than the exception. 

The remaining restrictions can be classified only as 
nuisances, but we feel you should be aware of them: all 
FETCH statements must be changed to LOAD state¬ 
ments; the relocatable library modules cannot contain 
common control statements. PHASE statements, or un¬ 
named control statements if they contain ADCONS; and 
the load address for Cobol overlay routines must be de¬ 
termined by the user and specified to DOSRELO. 
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(Depending upon the skills and sentiments of user per¬ 
sonnel, the last could quickly become a problem.) 


On the positive side, DOSRELO features normal entry 
point override to change the normal phase entry point; 
common control sections in problem programs; and im¬ 
mediate aborts in case fatal compile errors have occurred 
in a previous step. The last capability is particularly sig¬ 
nificant, for it prevents DOSRELO from wasting time 
with dead programs. 


FEES AND SUPPORT 

The purchase and rental fees include documentation 
and free maintenance for the length of the lease or life of 
the installation. 

HEADQUARTERS 

BMS Computer, Inc. 

P.O. Box 3086 
Walnut Creek CA 94598 
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GENERAL 

Spooler (Simultaneous Peripheral Operations On Line) 
is an automatic spooling system that handles printer 
outputs for local and remote jobs in a multiprogramming 
mode. 

The package runs on the IBM System/360 and 370 
(DOS) with a minimum of 24K bytes of main core storage, 
and requires 4K or 6K bytes for its partition plus between 
20 to 30 cylinders of an IBM 2311 or 23 14 Disc Drive for 
auxiliary storage. Users communicate with the system via 
a 1052 Console Typewriter, and the source language is 
BAL. 

Spooler may be rented for $195 per month or 
purchased for $3,500. Discounts are offered for multiple- 
location purchases. 

PACKAGE DESCRIPTION 

Spooling is a technique that has been used for some 
time to decrease problem program execution time by in¬ 
tercepting supervisor calls (SVCs) for unit record 
devices, and placing the output data on a magnetic 
storage device. After the problem program runs to 
completion, the data is retrieved from storage and 
printed. Quite simple? Yes, but also quite costly in auxil¬ 
iary storage space, amount of time required to ultimately 
print the data, and overhead incurred by having printers 
and punches sitting idle while the data is being spooled. 
In fact, conventional spooling is so time-consuming that 
some packages have no mention of print times in the per¬ 
formance data. 

To counter conventional spooling deficiencies, a 
number of spooling packages have recently emerged. 
These systems generally use the same techniques as con¬ 
ventional spooling to transfer record data to and from 
auxiliary storage but differ in the way I/O commands are 
handled and records are sorted. Many of the newer 
systems either use their own supervisor or modify the 
host system supervisor. Spooler uses its own supervisor. 

Spooler is a combination spooling and buffering 
system, which resides in a foreground partition (either 
FI or F2) and spools output data to a user-designated 
printer. Since the package handles multiprogramming 
operations, the host operating system must have a mul¬ 
tiprogramming supervisor and a data protect feature. 

Spooler is available in 4K- or 6K-byte versions, which 
are functionally and operationally the same but differ in 
output capabilities. 

A principal feature of Spooler is its ability to output 
data to a buffer area, and then ultimately to a printer 
while the problem program is still executing. This 
asynchronous operation is possible because of the way 
the Spooler supervisor handles I/O interrupts. In opera¬ 
tion, the problem program issues supervisor calls (SVCs) 


in the usual manner. At this point the Spooler supervisor 
comes into operation. Spooler traps and analyzes the 
SVC to determine if the ultimate I/O device called for is 
one under its control. If so, the data is transferred to a 
disc associated with that device; if not, operations con¬ 
tinue in the normal DOS fashion. 

Spooler uses a disc storage unit and associated core 
buffer to store data and output it to an assigned printer. 
Data bound for output is initially loaded to disc where it 
remains until enough lines are accumulated to fill its as¬ 
sociated core buffer. This buffer is then loaded and in 
turn “feeds” the assigned printer. Data is printed a line at 
a time until the buffer contents are exhausted. 

Spooler offers some notable features that are not 
found in most of its competitors, particularly in the areas 
of printer control and printer queue management. In ad¬ 
dition, the system has a “warm” restart capability to 
handle hardware and software failures. 

Task management features (i.e. print control) allow 
the operator to control initialization, termination, and 
operations of printer tasks. Specifically, the operator 
may display the status of all jobs in the printer queue, 
restart printing of a current job which was either inten¬ 
tionally or inadvertently halted, halt/pause the current 
job being printed and resume printing of a halted job, 
and cancel the current job being printed. In addition, the 
operator may forward or backspace the printer a specific 
number of pages, and terminate the Spooler routine en¬ 
tirely, thus reverting back to DOS control. All such ac¬ 
tions are initiated from a Model 1052 Console Typewrit¬ 
er. 

Queue management permits the operator to control 
the output printer queue and its operations using the 
1052. He can display the status of one or all jobs in the 
print queue, start printing the highest-priority job or any 
job in the queue, change priorities, hold/prevent jobs 
from printing, delete a single job in the print queue (a 
valuable feature if bad data exists), delete all jobs in the 
print queue, and modify the forms ID and/or number of 
print copies specified originally. 

The recovery facility, or “warm” restart as it is some¬ 
times called, permits the operator to restart the problem 
program at the point where it went “down,” in the event 
of a hardware or software failure. The Spooler restart fa¬ 
cility is functionally similar to IBM’s warm restart fea¬ 
ture available under OS, in that it records program 
checkpoints and cycles back to these checkpoints to re¬ 
cover and restart the program. This feature is extremely 
valuable, for without it the entire program would have to 
be reinitiated. 

Spooler, however, does have two significant draw¬ 
backs, both of which result in high disc overhead and, in 
some cases, printer overhead. The first drawback is the 
number of print lines a typical core buffer can hold. The 
4K-byte version, for example, is limited to four lines per 
buffer, while eight lines are considered normal for the 
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6K Spooler. (Both capacities could be increased if the 
user were willing to spare the core, but four and eight are 
the average in a 24K-byte machine.) These limited buffer 
sizes will, in all likelihood, cause a significant amount of 
data overflow to disc, where it will remain until the 
printer can service it. 

The second drawback is that data bound for different 
printers cannot be intermixed on the same disc; i.e., a 
separate printer must be devoted to each disc. In all 
fairness to Booth, however, we must point out that the 
excellent print control and printer queue management 
features of Spooler would be quite difficult to implement 
if this approach were not used. 

Input. Inputs to Spooler consist of SVCs intercepted 
from the problem program, any operator instructions, 
and the actual data to be output. 

Process. The data bound for output is first loaded 
into a designated buffer area, which has a particular 
printer associated with it. When the printer buffer is 
fully loaded, Spooler issues a Channel Command Word 
causing data to be output to the printer. When the print¬ 
er buffer completely empties, the disc loads it with the 
next print lines. 

Jobs are spooled to buffers on a first-in, first-out basis 
although the operator may assign priorities to jobs once 
they are in the print queue. 

Output. Output consists of problem program data 
and status messages requested by the operator. 


FEES AND SUPPORT 

The purchase price or rental fee includes documenta¬ 
tion, a lifetime guarantee against source code bugs, and 
free enhancements. 

Installation. Installation requires about five minutes 
and is accomplished by link-editing Spooler into the 
system. The vendor will assist with installation if 
requested, but this can generally be done by following 
the instructions in the systems operations manual 
supplied. 

Documentation. Purchased versions are delivered in 
source or object code—whichever the buyer requests. 
Rented versions come in object code only. The only 
printed documentation supplied is a systems operations 
manual, which serves as an operators’ manual and a 
users’ guide. It contains a very brief system overview; 
listings of console commands and associated actions, 
console messages and associated meanings, and installa¬ 
tion instructions; and examples of system use. 

Maintenance. The system carries a lifetime guaran¬ 
tee against source code bugs, and all enhancements are 
provided free. 

HEADQUARTERS 

BMS Computer, Inc. 

P.O. Box 3086 

Walnut Creek CA 94598 
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OVERVIEW 

Amigos is offered as a substitute for IBM’s ISAM file 
access method. It allows intermixed random and sequen¬ 
tial processing in Cobol, floating storage positioning of 
file location indexes, and dynamic reorganization of files. 
The package runs on an IBM System/360 Model 40 and 
above operating under OS, DOS, VS1,VS2, or DOS/VS. 

A 3-year license agreement is $17,000 including in¬ 
stallation; an 18-month lease is $700 per month plus a 
$2,000 installation fee; and a 2-month lease is $1,000 per 
month plus a $2,000 installation fee. Various discounts 
are offered for multiple copies. The package is immediate¬ 
ly available. 

Amigos was first installed in September 1970 and now 
has 90 users. Three releases have been issued since the 
original version. 

DESCRIPTION 

Access Method for Indexed Data Generated for 
Operating System/360 (Amigos) was developed by Data 
Art Corporation, a Comress subsidiary, as a substitute 
for IBM’s Index Sequential Access Method (ISAM). 
Functionally, both read and write data, block and 
unblock logical records, process standard labels, detect 
errors and correct them whenever possible, and provide 
linkages to user error and label routines. Amigos, in ad¬ 
dition, supports all options of BAL, Cobol, PL/1, and 
Fortran and handles fixed or variable length records 
under OS and DOS. (The variable length feature is op¬ 
tional.) 

Like ISAM, Amigos uses a nucleus program to access 
files and enter read/write functions, and control blocks to 
hold the parameters concerning each file being con¬ 
trolled. Amigos, however, uses the same accessing 
method for random and sequential retrievals and 
employs the same control block to handle both types. 
ISAM uses a separate control block and a separate 
nucleus for each of these types of retrieval. 

The record storage and record searching techniques 
employed by Amigos contribute heavily to its overall ef¬ 
ficiency. The record storage technique is designed to 
save device read/write time during sequential accessing 
by decreasing the time required to retrieve a record from 
disc. This is effected by interleaving the data blocks—as 
opposed to blocking them in sequential order—on the 
disc track. Under interleaving, one data block is written 
in one location and another is written, say, two locations 
away. This allows the machine the equivalent of one 
block and accompanying interrecord gaps to read and 
process the first block before the read head reaches the 
second block. The important factor here is that both 
readings are accomplished during the same disc ro¬ 
tation—which isn’t always the case with sequential 
reading. 


Amigos also permits intermixed random and sequen¬ 
tial processing of the same file by Cobol programs, with 
only one open file required. Provisions have also been 
made to store data in secondary disc areas when more 
space is required than allocated. This feature allows the 
user to allocate disc space based on a close estimate of 
the file’s actual size. 

Another effort to increase throughput is reflected, in 
the indexing and the block addressing techniques 
employed. The Amigos indexing technique stores the 
master index in core (to reduce overall search time) and 
locates the records by using a cylinder and block index. 
This identifies the track holding the record and the exact 
block on the track. Generic searches can also be done in 
any of the supported languages. Here, the file is scanned 
and positioned to the first of a particular class of records; 
and sequential accesses may be made to retrieve all 
records of a designated class. 

The file management techniques employed by Amigos 
in both the prime data and overflow areas are also aimed 
at efficiency by reducing the number of records in the 
overflow area, increasing the storage density in these 
areas, and reducing the frequency of file reorganization. 
In both areas, data is stored in blocked form. 

All Amigos files are reorganized dynamically. In the 
prime data area a record designated for deletion under 
Amigos is actually deleted from the block, thus creating 
a gap. If during subsequent processing a record is added 
that will fit into a gap, it is added directly. If not, it is 
stored in the overflow area. Since records stored in the 
overflow area are blocked to provide greater density, less 
frequent reorganization is necessary. When the user- 
designated upper limit for records in the overflow area is 
reached, all records on that cylinder are reorganized into 
the prime data areas and processing continues with a 
newly reorganized cylinder. 

Amigos has a “threshold warning” feature which auto¬ 
matically alerts the user whenever the total amount of 
disc space available for dynamic data set reorganization 
drops below a previously specified level. This prevents 
unpredictable abnormal terminations and allows orderly 
scheduling of file reorganization. 

Any Amigos I/O statements coded for a DOS environ¬ 
ment will function identically in an OS system (and vice 
versa). Amigos files and programs can be created under a 
DOS system and subsequently processed under an OS 
system (and vice versa) without modification. 

Amigos is compatible with the IBM 360 operating 
system and therefore can be implemented via user-coded 
I/O routines. To convert from ISAM to Amigos, howev¬ 
er, the program linkage and file formats must be changed 
to meet Amigos requirements. Program changes can be 
attained with no modifications to the logic of the 
application programs. The only changes necessary are to 
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replace ISAM input/output statements with their Amigos 
counterparts on a one-to-one basis. With BAL programs, 
these changes may be effected by manually scanning the 
source listings for ISAM I/O statements and replacing 
them with Amigos counterparts. For programs written in 
Cobol, the vendor supplies a program that converts the 
applicable I/O statements. PL/1 and Fortran are 
implemented via an interface. 

For OS, VS1, or VS2 operating systems, a transpar¬ 
ency option is available which allows programs written 
with ISAM I/O statements to process Amigos data sets 
without change or re-compilation of the program. The 
JCL statements are modified to indicate the change from 
ISAM to Amigos. The transparency option does not af¬ 
fect the operation of ISAM on data sets which have not 
been converted. 

Because Amigos is designed to be a complete replace¬ 
ment for ISAM, it accepts the same type of data. Some 
modifications to the application files, however, are nec¬ 
essary to make them compatible with Amigos. The sup¬ 
plier offers a program that performs these conversions 
and writes the converted files on disc. Conversion 
requires about 20 minutes per disc pack. 


SUPPORT 

Included in the purchase price are installation (only in 
3-year license), training, and documentation. The suppli¬ 
er allows up to five man-days to aid with conversion 
problems, install the package, and train user personnel in 
system concepts and operation. Documentation consists 
of a users’ manual. 

The supplier guarantees that Amigos will operate 
error free for the life of its installation. Most system en¬ 
hancements are available at no additional charge for 
three years, although in some cases a nominal fee may be 
charged for a major enhancement. After the first three 
years, updates and improvements can be purchased for 
$2,500 per year. 


HEADQUARTERS 

Comress 

Two Research Ct 

Rockville MD 20850 
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OVERVIEW 

The Executor may be used as a direct replacement for 
or in conjunction with the OS Initiator or Scheduler, and 
performs basically the same functions: allocating 
resources for each job, and establishing each job step as an 
executable task. The Executor, however, is much more ef¬ 
ficient and also eliminates many OS shortcomings in job 
management. It can process current job streams with no 
JCL changes, and is purported to reduce total real-time 
job execution from 25 to 50 percent. 

The Executor runs on the IBM System/360 or 370 
under OS/MFT or MVT with HASP. The system is linked 
and cataloged into the system library. Main storage 
requirements range from 16K bytes plus IK for each con¬ 
current Executor processor, plus the total size of all ac¬ 
counting routine exits if only the Executor nucleus 
module is core resident, to 28K bytes plus 1K per process¬ 
or if all modules are in core. 

Users are offered the Executor under a perpetual lease 
price of $20,000 per CPU, or it may be leased for $350 per 
week per CPU. A service fee of $700 is levied for installa¬ 
tion and training. (See SUPPORT.) 

DESCRIPTION 

The Executor is essentially a job management process¬ 
or which runs under HASP and performs functions simi¬ 
lar to the OS/MFT Initiator or OS/MVT Scheduler. It is 
designed to decrease the total real-job time (not CPU time 
or real execution time) by eliminating the scheduling and 
resource allocation hang-ups inherent with OS/360 and 
370. (See EVALUATION.) The system is totally trans¬ 
parent to the user, but operators will have to learn some 
slightly different message formats. 

With the Executor, you have the option of running it 
stand-alone or in conjunction with the system scheduler or 
initiator. Initially, most shops will probably opt to run 
them together, since there are some jobs the Executor 
can’t handle. The Executor determines its jobs by scan¬ 
ning the JCL; non-Executor jobs are passed via HASP to 
the system scheduler or initiator for handling. 

Jobs the Executor cannot handle are: those requiring 
the use of the checkpoint/restart; those where new ISAM 
data sets are being created; those where catalogs are 
changed outside the JCL; those where DASD data sets 
require more than five volumes; and those where many 
DD statements may require more core for initiation. 

The HASP interface to support the Executor affects 
only the XJ 12 overlay in HASPXEQ. Here the decision is 
made to either run the job under the Executor or pass it on 
to the system scheduler or initiator. 

Non-Executor jobs may subsequently be reexecuted ei¬ 
ther directly by the host initiator (HOSINIT) or by an ini¬ 
tiator invoked directly by the Executor. If the latter 


approach is taken, the host reader (HOSRDR) is unneces¬ 
sary; this frees the region reserved for it in the dynamic 
area, and releases the system queue space required for 
HOSINIT (about 2088 bytes each). 

If the job is for the Executor, HASP scans the TCB 
chain to verify that there is an Executor processor han¬ 
dling the HASPINIT (PIT) under which this job is being 
run. If not, or if the job is not to run under the Executor, 
HASP routes it to the HOSRDR. Otherwise, HASP posts 
the appropriate Executor with the address of the JCL 
DDB for this job, and provides the Executor with 
addresses of internal HASP control blocks. 

Scheduling and Resource Allocation 

The Executor employs a different philosophy and tech¬ 
nique to select and initiate jobs and allocate resources. 
Under OS and HASP, jobs in each queue are selected and 
initiated on a first-in, first-out (FIFO) basis. Also, HASP 
uses serial readers to effect its FIFO operation. 

The Executor, on the other hand, employs nonserial 
readers. This allows the parallel reading and interpreting 
of several jobs, but does not guarantee FI FO initiation due 
to the way resources are scheduled. 

Under OS and HASP, resources are allocated to a job 
required. Thus, a job could conceivably start execution 
without having sufficient resources available to finish 
uninterrupted. 

With the Executor, no job is initiated unless all the 
resources required to allow it to run to completion are 
available. If the Executor cannot initiate the entire job 
because of the unavailability of some resource, it returns it 
to its queue and takes the next job in line and attempts to 
initiate it. This action continues until a job is found that 
can run with the available resources. As you can see, this 
is quite a departure from the FIFO technique of OS. 

The Executor uses catalog lookups to allocate devices. 
For DASD, it uses the volume information obtained from 
the catalog at job start. For tape devices, it uses the catalog 
initially only to identify the device type; it accesses the 
catalog again at step-start time for the actual volume in¬ 
formation. 

There are several differences in the way the Executor 
handles volume mounts. Under OS, core is allocated when 
mounts are requested; with the Executor, no core is 
allocated prior to the mounting of volumes. U nder OS, the 
initiator attaches a job step while tape mounts are pend¬ 
ing; under the Executor, the operator must satisfy all 
mounts before a job step is attached. Also under OS, unit 
addresses are allocated from low address up. This creates a 
condition whereby a disc could be removed from one 
drive in order to mount another, and then the dismounted 
disc is needed immediately on another drive. The Execu¬ 
tor’s algorithm prohibits any volume from being dis¬ 
counted if it will be required later. 
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A special Roll option is offered with the Executor to 
allow auxiliary DASD storage to be used during interpre¬ 
tation and allocation processing to handle jobs with large 
amounts of JCL. Such jobs will probably require an ex¬ 
tremely large startup region, and could easily exceed the 
space reserved for this purpose. Without the Roll option, 
such jobs would have to be required to the OS for execu¬ 
tion. Or, if that is unacceptable, the user would have to 
reserve a large startup area. With the Roll option, the 
large jobs merely spill over to a DASD. 

The Executor also uses its own Global Balancing Tech¬ 
nique to optimize channel and device usage. Rather than 
attempt to balance channel and device load with each job, 
it balances activity across all active Executor jobs. This is 
an excellent feature, and should result in improved 
channel and device utilization. 

The Executor offers a generalized pooled work data set 
facility which is something similar to OS’s dedicated data 
set facility. Called Permanent Work Data Sets (PWDS), 
they are constructed at initialization from information 
supplied in the SYSEXEC Proc. Unlike the OS 
preallocated data sets, where the data set name in the job 
must be the same as the definition name specified in the 
initiator procedure, the PWDS does not have to be the 
same as that in the Executor procedure. 

The PWDS are shared among all concurrently active 
Executor processors. Each PWDS is completely reini¬ 
tialized prior to a new assignment. 

The Executor supports systems with or without SMF. 
For non-SMF systems, it supports the IEFACTRT ac¬ 
counting exits. For systems with SMF the Executor sup¬ 
ports all standard SMF functions, including all exits and 
applicable records. The exits and records are handled con¬ 
ventionally in accordance with the SMF options selected 
at IPL time. 


EVALUATION 

One of the principal functional hang-ups of OS/360 and 
370 is that a job may start processing without necessarily 
having sufficient resources available to finish uninter¬ 
rupted. This is compounded by the fact that a processing 
job always runs to completion unless canceled or inter¬ 
rupted by a higher priority job. Thus, a scheduled job 
awaiting needed resources just waits — and could block 
another job from being scheduled during this interim. 
Also, a waiting job may needlessly hold resources, thus 
denying them to other jobs. The net is that many jobs that 
could be scheduled aren’t, while jobs scheduled that are 
hanging for needed resources run-up total real time. 

Such conditions shouldn’t occur under the Executor 
due to the way it allocates resources. Instead of assigning 
devices to meet the needs of the immediate step, it 


allocates all devices to meet the needs of the entire job. 
This is done during a preexecution step. 

Preallocation offers the additional benefit of reducing 
the number of records in the OS job queue. Also, since 
there is no step-to-step allocation or deallocation (devices 
are automatically released after each step), Q4 is not 
needed for scheduling. 

Other benefits offered by the Executor are better bal¬ 
ancing of channels and device loads, and no premature al¬ 
locating of core during volume mounting. Both increase 
efficiency and reduce overhead. 

The effect the Executor has on real-time execution can 
be readily seen from the following benchmark run at a 
large university on an IBM System/360 Model 75 under 
OS/MVT with HASP residing in high-speed storage. 

Without Executor* With Executor** 


REAL 

CPU 

REAL 

CPU 

43.2 

8.72 

21.6 

8.86 

43.2 

8.88 

22.2 

9.39 

45.6 

6.40 

20.4 

6.53 

45.0 

7.09 

21.0 

7.07 

11.4 

1.89 

6.0 

2.00 


♦Includes the reader/interpreter time. 

♦♦Includes the reader/interpreter time performed thru the Executor. 

The principal Executor drawback is the fact that jobs 
running under its control cannot invoke the check¬ 
point/restart facility of OS. This could be a rather signifi¬ 
cant limitation in this era of multiprogramming and long 
jobs. If checkpoint/restart is needed, the user may nullify 
the Executor and resort to the conventional OS initiator 
and scheduler. Then, of course, you’re back where you 
started. 

Executor users interviewed were all quite ehtusiastic 
about the system. It performs to specifications, and all 
users report increased performance and reduced 
overhead. We agree that the Executor would be a wel¬ 
come enhancement to most installations. 

SUPPORT 

The purchase price includes installation, training, doc¬ 
umentation, and enhancements. 

The Executor is available on a 2-week trial basis, but 
the user must pay a $700 installation fee per CPU. This 
amount, however, is applied to the perpetual lease price or 
weekly lease charge per CPU should the user elect to 
purchase or lease the system. 

HEADQUARTERS 

Cutler-Williams 

2655 Villa Creek Drive 

Dallas TX 75234 
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GRUMMAN DATA SYSTEMS 
COPS 


OVERVIEW 

Grumman Data Systems’ COPS is a system monitoring 
program that reports to the operator via a CRT display the 
current status of jobs, tape drive, and disc allocation, thus 
allowing him to determine workload-resource relation¬ 
ships. It is written in ASSEMBLER language and runs on 
either the IBM System 360 or 370 under OS with 
MVT/HASP and requires 12K bytes of core. Either a 2260 
or a 3270 display system is required. No HASP or 
operating system modifications are required to run COPS. 

The license fee is $8,500 for the first year and includes 
installation, user documentation, and any new releases. 
Charges after the first year are $85 per month. Additional 
installation sites within the same company are licensed at 
45 percent of the primary installation fee. All maintenance 
and enhancements are included in these charges. 

This system was developed and tested in 1972 and was 
released for sale in 1973. To date, Grumman is the only 
user of the system. 

DESCRIPTION 

COPS provides communication between the 360/370 
operating system and the computer operator to achieve 
maximum system efficiency and job throughput. The 
system reads status or job information from HASP or OS 
control blocks and provides operators with status in¬ 
formation concerning the changing system environment so 
they can recognize workload-resource relationships. This is 
done through four console displays selectable by the 
operator and dynamically updated by the COPS system, 
based on the parameters established at COPS generation. 
The job activity display shows: 

• Job and step identification. 

• Initiator status. 

• Job status (RUN, WAIT, ENQ, ALLOC, etc.). 

• Resource usage (CPU, CORE, TAPE, DISC). 

• Status time stamps. 

The job backlog display shows: 

• Totals by class and priority. 

• Local and remote breakouts. 

• Print backlog. 

• CPU utilization. 

• Core availability. 

• Critical system parameters. 

The tape and disc displays show: 

• Unit status and availability. 

• Pending action. 

• Current volume. 

These displays are the heart of the system and may be 
generated on demand through a series of commands. The 
commands allow change of display, dump to the line 
printer, log on or off, and the writing of COPS display 
data to a disc data set at a particular interval. 


The activity display shows the status of jobs running in 
the system under HASP. Started tasks and jobs running 
under non-HASP initiators are not included. Job status is 
communicated continuously. The backlog display shows 
all jobs read by HASP waiting to be run. The display is in 
matrix form with OS job class across the top, and job 
selection priority down the side. Critical system parameters 
such as amount of queue space available, the number of 
I/O request queue elements which have been used since 
IPL, and the current number of I/O requests outstanding 
are shown. The tape and disc displays show all active 
devices on the system, as well as those that are off-line. Ac¬ 
tion codes on this display indicate that the device is not 
ready, has an outstanding mount, or should be unloaded. 
These allow prompt operator action. 

PROCESSING 

COPS is operator initiated, usually after each IPL, and 
runs continuously. If initialization is successful, the con¬ 
sole^) will be set to default displays established at in¬ 
stallation time. If problems are detected with initialization, 
an error message will appear at the main console noting the 
cause of the problem. 

Designed to run as an independent program providing 
visibility into the operating system, COPS is an interval- 
driven program which reads status and job information 
from HASP and OS control blocks. This data is logically 
divided into functional areas, formatted, and written to 
operator display consoles. 

A master control table defining the HASP and OS con¬ 
figuration and options is required. This table is dependent 
on the structure and content of the control blocks in MVT 
and HASP. As long as this control block structure remains 
unchanged, COPS is system- and release-independent. 

At start-up time, the initialization routine completes the 
master control table by storing HASP and OS addresses 
and control information required during operation. The 
executive routine is the commutator for all the COPS 
display routines. Each routine is given control at an in¬ 
stallation-set interval (normally 4 seconds) to format and 
output its display. At the conclusion of each cycle, any 
operator reply processing is performed. 

V 


HEADQUARTERS 

Grumman Data Systems Corp. 
South Oyster Bay Rd 
Bethpage NY 11714 
(516) 575-0574 
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The display output routine issues exception writes to 
specific lines on specific consoles at the request of each 
display routine. In cases where hardcopy is requested by 
the operator, the display records are written to a print data 
set. 

EVALUATION 

This package should offer tremendous advantage to the 
operation of heavy volume systems with multiple remote 
terminals. At its only installation, 35 high traffic RJE ter¬ 
minals feed jobs to the system; all jobs demand tape and 
disc mounts. Through the use of the informative COPS 
displays system, operators are able to respond to bot¬ 
tleneck situations rapidly, and thereby improve through¬ 


put. The displays also signal when various devices should 
be unloaded, thus providing more complete and efficient 
system utilization. 

In conclusion, if you are operating in multi-user 
MVT/HASP environment, COPS offers some powerful 
system control functions. 

SUPPORT 

The license fee includes installation and maintenance, 
three copies of the User’s Guide Manual, and new releases 
as they become available. Installation takes one man-day 
according to the vendor. 
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GENERAL 

UCANDU is a dump/copy utility for the IBM 
System/360 running under OS. Source language is As¬ 
sembly Language and Cobol. 

The minimum configuration is an IBM System/360 or 
370 computer (OS) with a main storage of approximately 
48K bytes plus a buffer area for user files. Any 
input/output devices can be used to dump or copy data 
sets. The package runs under OS (MFT, MVT, or VS). 

UCANDU is available for purchase at $1250 or at a 
rental price of $50 per month. The first 9 months rental 
apply toward the purchase price. 

The package is immediately available. It was first in¬ 
stalled in November, 1969, and has been steadily 
improved in recent years. It now has about 30 users. 

DESCRIPTION 

UCANDU is a general-purpose utility that dumps or 
copies specified records from any file supported by IBM 
OS. It is device-independent and allows the user to select 
records for processing based on file position, record con¬ 
tent, or both; to copy an input file to another peripheral 
medium; and to begin or end processing anywhere in the 
file. 

By varying the parameters that define the dump, copy, 
or list action, the user can employ UCAN DU for a variety 
of functions. For example, for program testing, files can 
be selectively dumped or listed, and test files can be 
generated from live files. The package can also be used to 
reorganize or back up indexed sequential data files; it au¬ 
tomatically gives statistics on prime and overflow areas. 
Other uses of the package include program output verifi¬ 
cation. auditing, file sampling, and merging of source files 
to create program libraries. 

Input. UCANDU is invoked through OS JCL, 
followed by four types of parameter cards; action 
director cards, data selection criteria cards, logical con¬ 
nector cards, and comment cards. 

The action director cards describe the functions to be 
performed, including actions (dump, list, copy) and 
parameters governing the action (for example,to specify 
hexadecimal interpretation and starting and ending loca¬ 
tion in the file). The data selection criteria cards define 
the data to be acted upon either by location (fields in log¬ 
ical records of a file) or by content (through relational 
operators used with specific values). The logical con¬ 
nector cards logically connect the selection criteria 
through "and" or "or" relationships. Since the system au¬ 
tomatically defaults to the "and" relationship unless “or” 
is specified, "and" cards are used only for documentation 
purposes. Comment cards are used for documentation 
and are printed with parameter cards in the order in¬ 
troduced. 


Process. The package consists of two modules; One 
performs I/O functions, and one interprets user requests 
and edits data records. The two UCANDU modules 
communicate through calls to extract the user-specified 
records from the input file and dump, list, or copy them 
as requested. Once invoked, the program can handle as 
many functions and as many files as desired. 

UCANDU includes a self-monitoring facility that 
checks for internal errors or unusual “wait” conditions 
every 10 minutes. If it encounters a problem condition, 
the facility sends a warning message to the operator and, 
if the problem condition is unresolved after 30 minutes, 
aborts the program. When a program is aborted, the 
package performs an automatic dump if the output 
device specified is a printer. 


Output. The user-specified records are printed with 
or without a hexadecimal interpretation. The system also 
provides messages giving status information on user 
requests and on files being processed. Relative record 
numbers annotate printed output. 


Evaluation. UCANDU competes with IBM’s free 
dump and copy software and with other vendors’ 
operating system enhancement packages such as West- 
inghouse's Dump/Restore/Copy. According to Gulf, 
some significant features of UCANDU are that it is 
simple to use, is parameter-driven, handles indexed 
sequential records rapidly, and has flexible data selection 
criteria. Users we contacted agreed; they found the 
package easy to use and highly versatile. One user crit¬ 
icized the package for high core requirements (approxi¬ 
mately 50K), but another disputed that criticism. 

Users were also pleased with UCANDU’s perform¬ 
ance and with Gulfs support. One problem encountered 
is that users’ expectations sometimes exceeded the 
package’s capability. Two limitations of UCANDU, for 
example, are that replacements must be done one step at 
a time and that there is no report generation capability. 

In general, no support from Gulf was required. How¬ 
ever, users said that Gulf responded promptly if ques¬ 
tions arose or problems with unusual files occurred. 

According to users, the cost of the package (as op¬ 
posed to IBM’s free software) is justified by the savings 
in programming time that result from the package's ver¬ 
satility. 

SUPPORT 

Price of the package includes documentation and first- 
year maintenance. UCANDU is link-edited and invoked 
as any other OS job. No on-site installation assistance 
from the vendor is required. Users train themselves 
through the user’s manual provided. 
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Gulf supplies the program on a mini-reel of magnetic 
tape and provides 10 copies of the user’s manual free. Ad¬ 
ditional copies of the user's manual are available at extra 
cost. The vendor corrects program errors and furnishes 
minor enhancements free for the first year. 


HEADQUARTERS 

Gulf Oil Computer Sciences, Incorporated 
P. O. Box 2100 
Houston TX 77001 
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OVERVIEW 

Fast Dump Restore (FDR) is a utility program that 
dumps 2314, 2319, and 3330 Mod I and Mod II disc 
packs or their plug-compatible equivalents to magnetic 
tape and restores packs from the tapes. FDR does not 
require a change to the operating system. 

FDR runs on an IBM System/360 Model 40 and up or a 
System/370 Model 135 and up under PCP, OS/MFT, 
OS/MVT, OS/VS1, or OS/VS2. It requires 64K bytes of 
core for 2314 discs and 100K for 3330 discs. Source lan¬ 
guage is Assembler. 

FDR costs $1,500 for unlimited use on the first CPU 
and includes an object deck and user documentation. For 
each additional computer system, the price of FDR is 
$750. To add the 3330-1 1 version for any system for 
which an older version has been purchased costs an addi¬ 
tional $200. A copy of the source code on tape costs an ad¬ 
ditional $50. 

Introduced in July 1972, FDR is operational in over 
800 installations. New features are added periodically and 
are supplied to users generally without charge. Significant 
enhancements are offered at a slight fee to users. A stand¬ 
alone restore program (FDR-SAR) is available free of 
charge. 

DESCRIPTION 

FDR is designed to replace the dump and restore 
functions of IBM's IEHDASDR. The vendor claims that 
FDR is significantly faster, uses less tape, and is more re¬ 
liable in handling bad tracks. 

Vendor's comparison figures seem to back up the 
claim. Both packages dumped and restored a full disc 
pack with other jobs active in the system, causing inter¬ 
ference on the channel, control unit, and disc spindle 
during the operation. FDR dumped the disc packs in 15 
to 30 percent of the time required by IEHDASDR and 
restored them faster than the dump operation. 

FDR's speed is achieved by utilizing dynamic buffer 
management and highly overlapped tape and disc I/O, as 
compared with IEHDASDR’s track-by-track, unover¬ 
lapped, serial operation. FDR reduces disc channel con¬ 
tention by processing all tracks of a cylinder without 
losing a revolution. Speed is limited only by the data 
transfer rate of the tape drive. 

FDR employs single-record track formatting and 
blocking techniques to improve tape transfer speed and 
reduce tape channel contention. This method requires 40 
percent less tape than that used by IEHDASDR and 
reduces tape mounts for multiple reels. 

During a restore operation, FDR uses the alternate 
track assignments, if any, of the pack to which it re¬ 
stores. IEHDASDR retains the alternate track assign¬ 


ment of the disc that was originally dumped, which can 
cause data to be written on bad tracks of the new disc 
and thus become inaccessible. FDR eliminates this 
problem entirely. 

FDR also offers the option of restoring the original 
volume serial number of the dumped pack to the re¬ 
stored pack or retaining the volume serial number of the 
new pack. 

FDR has five options: 

• Dump one pack; core required (depending upon OS 
options) is 64-68K for 2314 and 92-96K for 3330; 
no PARM is used. 

• Dump several packs (up to nine) serially; core 
required (depending upon OS options) is 64 to 68K 
if all packs are 2314s and 92 to 96K if any pack is a 
3330; no PARM is used. 

• Dump several packs (up to nine) concurrently; core 
required (depending upon OS options) is approx¬ 
imately 6K plus 56K for each 2314 being dumped 
and 90K for each 3330 being dumped; PARM-A is 
used; this is the ATTACH option. 

• Restore one pack, giving the restored pack the vol¬ 
ume serial of the dumped pack; core required 
(depending upon OS options) is a maximum of 50K 
for 2314 and 80K for 3330; PARM-R is used. 

• Restore one pack, retaining the volume serial of the 
pack being restored to; core required (depending 
upon OS options) is a maximum of 50K for 2314 
and 80K for 3330; PARM-N is used. 

PROCESSING 

Input 

In addition to the tape and disc involved in the dump 
or restore operation, FDR requires a group of JCL state¬ 
ments which describe the job and the I/O units involved. 

Process 

FDR reads and validates the JCL. Missing or errone¬ 
ous statements cause the job to terminate (as do hard¬ 
ware malfunctions) once FDR has begun processing. 

Any data written according to standard IBM program¬ 
ming specifications, including all standard access 
methods, can appear on the disc pack being dumped to 
tape. 

During a restore operation, FDR handles input tapes 
created by FDR or IEHDASDR. Upon detecting an 
IEHDASDR tape, FDR sets up the necessary control in¬ 
formation and invokes IEHDASDR. Therefore, FDR 
can be used for all dumping and restoring; the user need 
not distinguish between FDR and IEHDASDR backup 
tapes. 

If it encounters an abnormal condition, FDR enters 
diagnostic routines to assess the problem and report the 
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problem to the user. FDR will attempt to complete the 
dump or restore on minor problems. 

Output 

In addition to the tape (containing the contents of the 
dumped disc) or the restored disc, FDR prints diagnostic 
and console messages to inform the operator of a 
completed job or any unusual conditions that occurred. 

EVALUATION 

Using IEFIDASDR as a yardstick, FDR offers several 
advantages. Because of FDR's speed, computer pro¬ 
cessing time is saved; it also uses 40 percent less tape than 
IEFIDASDR. With these points in mind, a user can re¬ 
store a disc pack from tape, thus saving disc space. Using 
disc in this manner eliminates time-consuming disc 
mounting and dismounting. 

In our initial evaluation of FDR, we noted that the 
system lacked a partial dump facility — something which 
was offered with IEHDASDR. The vendor has corrected 
this shortcoming with an option feature called Data Set 
Functions, which allows dumping data set by data set or 


absolute track by absolute track. In addition, a data set or 
track can be restored from a full FDR or partial DSF 
backup tape. 

Users interviewed believe FDR operates in 10 to 35 
percent of the time that IEFIDASDR requires, 
depending on the tape density and number of tracks. 
They feel it is an invaluable moneysaver for a very rea¬ 
sonable price. 

SUPPORT 

Included in the package price is a 30-day free no 
obligation trial, as well as documentation and mainte¬ 
nance. The user is responsible for installing FDR and 
briefing his personnel in its use. 

Documentation consists of a concise package descrip¬ 
tion detailing capabilities, installation, and operation. 

HEADQUARTERS 

Innovation Data Processing 
925 Clifton Ave 
Clifton NJ 07013 
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OVERVIEW 

Anyplace II is an IBM System/360 or 370 DOS en¬ 
hancement designed to allow user programs and system 
software to automatically relocate and run in any suitable 
partition. The package works with Assembly, Cobol, 
PL/1, Fortran, and RPG object modules constructed as 
monolithic or multiphase. 

The minimum partition size for Anyplace II is 10K 
bytes on either the System/360 or 370. Like many of its 
competitors, the package does append code to the DOS 
supervisor; in the case of Anyplace II this amounts to 
about 150 bytes. 

Anyplace II can be leased for $99 per month or 
purchased for $1,800; additional installations cost $100 
each. A 30-day trial period is offered. 

DESCRIPTION 

Anyplace II functions as a linkage editor preprocessor, 
adding a control section to each phase of a program, to 
allow monolithic or multiphase programs to be relocat¬ 
able. Anyplace processes linkage editor input from the 
SYSLNK file and the relocatable library to create a new 
SYSLNK input file, which is then automatically link 
edited to produce programs that are self-relocating. 

Anyplace II requires no changes to the problem pro¬ 
grams or to the linkage editor. Anyplace never writes in 
the user’s library; all cataloging is done by the installa¬ 
tion’s unmodified linkage editor. Code is appended to 
the DOS supervisor, however, modifying it somewhat. 
This code is added either at SYSGEN time with a macro 
called SGANP (for System Generation Anyplace) or at 
any time thereafter with a separate initializer called 
ANYINIT (for ANYplace INITializer). This ability to 
modify any supervisor in a few seconds allows Anyplace- 
processed programs to be run on any DOS, such as a 
service bureau’s. 

During program execution, the appended supervisor 
code examines each phase to determine if it has a self- 
relocatable flag. If so, a supervisor transient (supplied 
with the Anyplace II system) is called to load the phase 
into memory at the beginning of the partition. ADCONs 
are then resolved appropriately. After the program has 
been loaded, the added relocation-table control section 
is stripped off and the program is returned to its original 
size. 


EVALUATION 

If one were to perform a “flack” survey of DOS users, 
high on the gripe list would be nonrelocatability. Simply 
stated, this means that once an object module is desig¬ 
nated to run in a particular partition, it can’t be 
relocated to run in another. Aside from inconvenience, 
the lack of a relocatability feature can result in wasted 
resources and reduced job throughput. This is particu¬ 
larly true when a partition of suitable size, with accept¬ 
able peripherals, becomes available. Programs in the 
core image library can’t use it because they’re not as¬ 
signed to that area. Thus the partition sits empty and 
waiting jobs continue to wait. 

To get around this limitation, many users resort to 
redundant cataloging of the same program in the core 
image library. Although this practice does solve the prin¬ 
cipal problem, it also creates a myriad of smaller ones. 
For example, when the supervisor and/or partition size 
changes, recataloging is necessary. Also, redundant 
cataloging requires more disc space and separate JCL. 

With Release 28 of DOS (called DOS/VS) IBM has 
solved the nonrelocatability problem—along with a 
number of other DOS shortcomings. But DOS/VS is of¬ 
fered free only to System/370 Model 115 through 158 
users, a restriction many believe to be a marketing ploy 
to get System/360 users to trade up to the System/370 or 
move to OS. These alternatives, however, are unaccept¬ 
able to many users who either own, or like, their Models 
30, 40, and 50. And running OS on anything less than a 
Model 50 is pure folly. 

The most plausible option available to the forgotten 
many is to turn to independently developed packages 
that offer a relocatability feature. Systems such as 
GRASP and EDOS possess it, but only as part of a large 
sophisticated system. Then there are the simple “bread 
and butter” packages like Anyplace II which allow 
relocation—that’s all. 

SUPPORT 

The purchase price of the package includes source 
decks, documentation, and maintenance for one year. 

HEADQUARTERS 

Marcus Powell Associates 

2694 Doidge Avenue 

Pinole CA 94564 
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OVERVIEW 

Marcus Powell Associates’ CATALR is a utility 
package allowing IBM 370 Disc Operating System users 
to catalog compiler output directly into the relocatable 
library without punching object decks, using tape drives, 
or coding Job Control Language (JCL). 

It is written in Assembler language and can be used on 
any IBM system under DOS. 

Purchase price for the object version is $595, which 
includes a reference manual and a system programmer’s 
manual with installation instructions. 

The program was first released in December 1972. At 
present, there are 400 installations. 

DESCRIPTION 

This package fills a need of DOS shops: a way to catalog 
modules in the relocatable library as quickly and conven¬ 
iently as programs are cataloged in the core image library. 
Modular program design is facilitated by enabling 
programmers to compile a single module and then link- 
edit the entire program from the library. This technique is 
especially important in an environment where monolithic 
programs branch all around the partition, thus degrading 
overall processing. 

DOS users are supplied a routine called MAINT for 
relocatable library maintenance, but this only reads input 
from SYSIPT. Output from the compilers is either avail¬ 
able on SYSPCH or SYSLNK. Hence, getting an object 
deck from the compiler to the relocatable library has 
required one of three techniques. The first involved 
punching a card deck, which was transferred to a reader 
and read in again — a slow process at best. A second pos¬ 
sibility, requiring some facility at JCL, has the object code 
written on tape, which is then rewound and reassigned as 
an input stream is read in. The final technique is difficult 
because of the complexities of DOS system files on disc. 
Here a scheme is developed for assigning SYSPCH to a 
DASD extent, and then assigning SYSIPT to the same 
extent. 

CATALR reads input directly from SYSLNK, with 
only a CATAL or OPTION LINK card necessary before 
compilation. An execute card, with the new module name, 
follows the compilation in the jobstream control 
instructions. 

PROCESSING 

The CATALR root phase is loaded into a 10K DOS 
batch partition by job control, normally after a compiler 
has written object code on SYSLNK. CATALR initializes 
itself and checks the partition in which it is running. If it is 
executing in a foreground partition, there is a possibility 


that maintenance on the same library is simultaneously 
being performed from the background. A check is made 
to see if a unique relocatable library has been made. In 
other words, does a private library on a device not as¬ 
signed as SYSRLB in another partition exist? Execution 
continues unless a unique library is not available, in which 
case a message is written on the console requesting an 
“OK” or a cancellation from the operator. 

The relocatable library accessed is the private library 
assigned as SYSRLB in the partition, and may reside on 
either 2311, 2314, or 3330 direct access storage devices. 
The object deck is copied to the first available space in the 
relocatable library. Records are reblocked using an al¬ 
gorithm similar to that employed by MAINT. The use of 
CATALR is compatible with the use of CORGZ, 
DSERV, LNKEDT, MAINT, and RSERV with the same 
library. 

When module processing is completed the directory is 
updated. Each affected module is listed with the action 
taken (i.e., deleted, renamed, cataloged, etc.) noted. At the 
conclusion of data on SYSLNK, the single overlay phase 
prints a system status report showing percentage break¬ 
downs of library utilization (allocated, active, deleted, and 
available). 

EVALUATION 

The users to whom we spoke were enthusiastic about 
the results obtained from the system. The prime advantage 
was the convenience of not having to create object decks. 
Another feature that all users agreed upon was a definite 
savings in machine time and peripherals. One user of a 
360/40 claimed CATALR showed that one tape drive was 
unnecessary and therefore could be eliminated. 

The percentage breakdown of library usage was also 
noted as a valuable byproduct of this system. All to whom 
we spoke indicated that, even under the new pricing struc¬ 
ture, this system was the best buy in the software 
marketplace. 

SUPPORT 

The purchase price includes a relocatable object deck of 
about 200 cards, job control for link-editing, and three 
REP cards. Also, a reference manual and a systems 
programmer’s manual are provided. Installation instruc¬ 
tions are found in the systems programmer manual and 
are the responsibility of the user. The package is war¬ 
ranted against programming errors. 

HEADQUARTERS 

Marcus Powell Associates 

2694 Doidge Avenue 

Pinole CA 94564 
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OVERVIEW 

DFAST is a disc file management system which brings 
many of the file handling capabilities of IBM’s OS to DOS 
and DOS/VS users. The package dynamically allocates 
file space at OPEN time and releases unused space at 
CLOSE; offers a form of automatic volume recognition 
(optional); prohibits accidental deletion of files; automati¬ 
cally expires files; and allows files to be partition inde¬ 
pendent. DFAST does not modify the host supervisor, 
JCL, or user programs. 

The package runs on any model of an IBM System/360 
or 370 operating under DOS or DOS/VS, and does not 
require a separate partition. Rather, it runs in the super¬ 
visor transient area and uses 1,200 bytes for each program 
phase. The total DFAST system is written in BAL and will 
fit into 30 blocks of the user’s core image library. Discs 
supported include the 2311,2314, 3330, and 3340. 

DFAST may be purchased outright or rented on a 
monthly or yearly basis under the following price 
schedule: 

Rental 

Purchase Monthly Yearly 
DFAST Version $ $ $ 

Basic 5,625 225 202.50/ 

mo 

Basic with AVR 6,875 275 247.50/ 

mo 


A 30-day free trial is offered. 

Introduced in August 1973, the package currently has 
about 70 users. 

DESCRIPTION 

In all, DFAST offers seven facilities not available 
under the basic versions of IBM’s DOS and DOS/VS. 
These are: Dynamic File Space Allocation, Release of 
Unused File Space, Automatic Volume Recognition, 
File Concatenation, File Protection, File Deletion, and 
Partition Independence. 

Dynamic File Space Allocation 

The DFAST method of allocating file space relieves 
the programmer from the chore of specifying the starting 
relative track number when a file is created. Instead, he 
need only indicate the number of tracks required and the 
system will dynamically allocate space for files whose ex¬ 
tents reside on the user label track, the partition standard 
label track, or the system standard label area. File space 
is always allocated on cylinder boundaries; no split cylin¬ 
der files are permitted. The latter is really no restriction 
because the IBM sort doesn’t accept split cylinder files 
anyway. 

DFAST handles sequential, indexed sequential, and 


direct access files, plus system and compiler work files, 
SYSLST, SYSPCH, SYSLNK (assigned to disc), and sort 
work files. It will not allocate file space for core image or 
private libraries, private source statement libraries, or 
private relocatable libraries. 

Release of Unused File Space 

When a sequential file is closed, DFAST truncates the 
file size so that only the actual amount of file space used 
by the program is protected in the VTOC. The user may 
prohibit this truncation if he wishes, and should do so 
for files opened as sequential output but not accessed 
sequentially (such as DBOMP files). 

Automatic Volume Recognition 

The DFAST Automatic Volume Recognition (AVR) 
feature is much like the OS generic assignment facility 
you may be familiar with. The AVR allows the system to 
automatically make logical unit assignments by the serial 
number entered in the JCL extent card. The logical unit 
assignments are made automatically if the logical unit is 
unassigned or if the serial number in the extent card does 
not match the serial number of the device to which the 
assignment is made. 

In operation, the compiler, sort, and linkage editor 
programs check device types prior to opening the files. 
When using these programs, the assignments must be 
made to the proper device type, but not necessarily to 
the exact disc drive. When the file is opened, DFAST 
changes the assignment to the proper drive based on the 
serial number in the extent card. If a logical unit number 
is permanently assigned to a nondisc device; the user 
need only temporary unassign that logical unit number 
to allow automatic volume recognition. 

File Concatenation and Protection 

The DFAST claim to be able to do File Concatenation 
somewhat overstates its real capability. The system 
cannot concatenate files via calls in the JCL (the way OS 
does it), but merely places related files so that they will 
all be on the same disc pack. It’s not fancy, but it’s better 
than jumping from pack to pack. 

The File Protection facilities prohibit k ‘live” files from 
being deleted because they have not been date protected. 
If the number of days’ retention indicated on the DLBL 
card is zero or the explicit expiration date is less than the 
current date, DFAST forces a 1-day retention for 
DFAST allocated files. DFAST will not alter the expira¬ 
tion date for files not dynamically allocated by it. 

File Deletion 

Closed sequential files can be deleted by merely in¬ 
serting a delete parameter in the DLBL card. DFAST 
also provides a special support program to delete files 
when they are no longer needed. Based on information 
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in control cards or entered from the console, this pro¬ 
gram will find the file in the VTOC and give it an expira¬ 
tion date less than the current day’s date. The deleted 
area may then be assigned to other files. 

If a file resides on more than one volume, a delete 
statement must be provided for each pack where the file 
has extents. 

Partition Independence 

DFAST provides a facility for maintaining file 
uniqueness between partitions, while allowing the same 
file name on the same disc pack to be used by more than 
one partition at a time. DFAST accomplishes this by as¬ 
signing partition identification characters to the file 
name and, when the file is opened, changing these IDs to 
reflect the partitions the file is currently assigned to. 

EVALUATION 

DFAST was developed by Tower Systems, Fullerton 
CA., and was marketed and supported by that organiza¬ 
tion until January 1975 when it was acquired by Oxford. 
While the new owner is now responsible for full system 
support. Tower personnel are still “in the background” 
to lend technical support if necessary. DFAST is also of¬ 
fered, in a modified form, with the Computer Software 
Company's EDOS. 

Those of you who've had to work around DOS’s short¬ 
comings can fully appreciate what DFAST has to offer: 
you get many disc management facilities only available 
to OS shops, but without the expense and trepidations of 
a DOS to OS conversion. 


The DFAST high card undoubtedly is its disc space 
management facility. Allowing the user to specify how 
many tracks he needs and then truncating those not used 
significantly reduces hardware overhead. How much 
these savings add up to in the long run depends upon the 
number of files being handled and the frequency of use. 
If you’re running on a low-volume, one-pack-per-user 
basis, the savings of course won’t be as high as in an ac¬ 
tive multivolume shop. 

While DFAST is intended for DOS and DOS/VS in¬ 
stallations, it should find its greatest market in VS shops. 
Here its principal competition comes from VSAM, 
IBM’s access method and disc utility. While VSAM does 
reclaim unused disc space, it is, however, only mode 
compatible with programs written for ISAM files. 
DFAST does not have this limitation. 

SUPPORT 

The package is fully guaranteed against source bugs 
for the life of the installation. Although the vendor will 
install the system on an out-of-pocket expenses basis, 
most users will probably be able to get DFAST up them¬ 
selves since it only involves cataloging it into the user's 
core image library. 

Documentation consists of a user’s manual which is 
short and simple; DFAST is distributed in object code. 

HEADQUARTERS 

Oxford Software Corp. 

51 1 Main Street 

Fort Lee NJ 07024 
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OVERVIEW 

Sprint is an automatic spooling system for the IBM 
360/370. It operates asynchronously with a problem pro¬ 
gram, resides in FI, F2, or outside of the three normal 
DOS partitions, and uses the standard unmodified DOS 
supervisor in conjunction with its own supervisor. 

The system runs on IBM 360/22 and up or 370 (DOS or 
DOS/VS) with a minimum of 32K bytes of main core 
storage. It requires 2K to 4K bytes for tape spooling and 
4K to 12K per partition for the disc spooling programs. 
Minimum auxiliary storage is four cylinders per reader 
queue and 10 cylinders per printer queue (231 1, 2314, 
3330, or 3340). 

Rental starts at $ 180/month and includes printer 
spooling with job accounting. A 30-day trial, 1-year lease 
(10 percent discount), and purchase are also available. 

DESCRIPTION 

Spooling is a technique that has been used for some 
time to decrease problem program execution time by in¬ 
tercepting supervisor calls (SVCs) for unit record devices 
and placing the output data on a magnetic storage device. 
After the problem runs to completion, the data is retrieved 
from storage and printed. Quite simple? Yes. But also 
quite costly in auxiliary storage space, the amount of time 
required ultimately to print the data, and the overhead in¬ 
curred by having printers and punches sitting idle while 
the data is being spooled. In fact, conventional spooling is 
so time consuming, some packages using it fail to mention 
print times in performance data. 

To counter conventional spooling deficiencies, a 
number of spooling packages have recently emerged. 
These systems generally use the same techniques as con¬ 
ventional spooling to transfer record data to and from 
auxiliary storage, but they differ in the way I/O commands 
are handled and records are sorted. Many of the newer 
systems either use their own supervisor or modify the host 
system supervisor. Sprint uses its own supervisor in con¬ 
junction with an unmodified standard DOS or 
DOS/VS supervisor. 

Sprint is comprised of two basic programs. The first is a 
tape spool program which dynamically allocates buffers 
and is completely self-relocatable. Core requirements for 
this program are between 2K and 4K bytes. The second is 
a disc spool program which also dynamically allocates 
buffers and is completely self-relocatable, but requires be¬ 
tween 4K and 12K bytes of main core per partition 
spooled. Additional modules support Device Address In¬ 
dependence, Job Accounting, Relocatable Loader, and 
Partition Balancing. When running under DOS/VS in vir¬ 
tual mode, Sprint requires 2K of real core per partition 
spooled. 

The Sprint programs reside in a high core (FI, F2) or 
outside normal DOS partitions (in F0) and spool all I/O to 


or from readers, printers, and punches. The system does 
require a multiprogramming supervisor and storage pro¬ 
tect feature. 

A principal feature of Sprint is its ability to output data 
to a buffer area and then ultimately to a unit record device 
while the problem program is still executing. This 
asynchronous operation is possible due to the way the 
Sprint supervisor handles I/O interrupts. In operation, the 
problem program issues supervisor calls (SVCs) in the 
usual manner, and these calls are routinely analyzed by 
the host supervisor. It is at this point that the Sprint super¬ 
visor comes into operation. The program simply examines 
the address of the output device to determine if it is under 
its control. If so, the data is placed on a predesignated disc 
or tape; if not, control is returned to the DOS supervisor 
and operations continue in a normal fashion. 

Systems of this type usually assign a unit record device 
to a specific buffer storage area, load data into the buffer, 
and subsequently output the buffer contents to the device 
while the problem program is still executing. 

Generally the data being spooled is loaded into a core 
buffer with overflow data being placed on disc or tape. 
(Overflow occurs because the unit record device is too 
slow to service the buffer.) Data is printed a line at a time 
until the buffer contents have been exhausted. The con¬ 
tents of the core buffer are then dumped to disc or tape 
and new data is loaded. Sprint, however, uses a different 
approach. Instead of loading data into the core output 
buffer directly, it records it in disc or tape storage first. 
After one disc track has been accumulated, the data is 
loaded to the core buffer and the output operation begins. 

The size of the buffers used for storing output records is 
entirely up to the user, but the system only works with 
blocked physical records. Thus, for best utilization of disc 
or tape^and core and for reduced seek times, it is wise to 
block by disc track. This allows the use of smaller buffers 
without degradation since the data transfer from the 
buffer to the unit record device is limited by the speed of 
the device. 

In addition to disc spooling, Sprint spools to magnetic 
tape. The technique used to accomplish this is the conven¬ 
tional DOS method, but Sprint is able to use tape marks to 
denote individual files within a volume and force an end 
of volume condition before the end of volume reflective 
spot is sensed. 

Sprint has a forms alignment routine which enables 
print carriage characteristics to be conveyed to the spool 
routine. As lines are spooled out, the theoretical position 
within a page is maintained allowing proper handling of 
forms overflow. The forms alignment routine permits the 
perpetual reprinting of one page of print, pausing to allow 
adjustment until the operator is satisfied with the align¬ 
ment. A printer backspacing feature allows reprinting of 
pages in the event of a forms jam. 
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The system also offers priority, job bypass and job ac¬ 
counting routines, device address independence, a 
relocating loader, and partition balancing features. The 
priority routines allow the user to suspend processing of 
the spool and to enable the background partition to func¬ 
tion normally. The bypass allows the operator to bypass 
jobs he does not want to print or punch. 

Sprint’s accounting package is actually the standard 
IBM job accounting program; Oxford merely supplies 
code for activating it. Information such as job name, user 
information (16 bytes taken from each job card), partition 
ID, cancel code, record type (job step = S, last step of job 
= L), start time, phase name, high core used, CPU time, 
overhead time, stop time, all bound time, start I/O count, 
and total pages printed is given. Note that a forms inven¬ 
tory can be maintained with this information and that 
Sprint supplies accounting on its own spooling activities 
as well as each partition’s. 

The device address independence feature eliminates the 
DOS portability problem by obviating the need to have 
actual device addresses in ASSIGN cards. The user may 
refer to logical devices such as “DOl” instead of “130”. 
Sprint dynamically substitutes actual address at execution 
time. All substitutions are based upon the partition being 
used. 

The relocating loader makes all user programs self- 
relocating and also allows the user to manage his program 
library better by maintaining such information as the date 
cataloged and the date last used. The relocating loader 
handles the ANS COBOL Sort verb, requires no changes 
to the JCL, and does not increase the size of the user’s 
program. 

The relocating loader is built around a separate core¬ 
image load file, a single extent composed of three parts: 
the Directory, Phase Headers, and Phases. 

The Directory consists of 1,034- or 1,100-byte blocks, 
each containing 22-byte phase entries in collating 
sequence by phase name. The first record in the first block 
is a library status record and contains information such as 
number of active entries, number deleted, and so forth. A 
key associated with each block shows the name of the last 
phase in the block. Each phase entry points to the phase 
header and the phase itself. A typical allocation of ten 
23 14 tracks yields a capacity of 2,900 phase entries. The 
directory must begin on a cylinder boundary and has a 
maximum size of one cylinder. 

The Phase Headers precede each phase in. the library 
and are of an undefined record format ranging from 5 1 to 
1,078 bytes in length. They contain information such as 
date entered, date last used, user information from the job 
card, and relocation pointers. This header is used by 
Sprint and is not loaded into the user’s partition. 

The phases themselves follow the phase headers. These 
records are written in an undefined format and range in 


length from one byte up to an entire track. They are a 
mirror image of the phase just as it was link edited. 

The Partition Balancing feature essentially is an al¬ 
gorithm that keeps track of each executing partition and 
ensures that a high priority partition does not lock out a 
lower priority partition. 

Sprint also offers another feature called Marvel, which 
allows one or more disc spooling programs to operate out¬ 
side of a normal partition. Marvel begins execution as a 
normal FI program, attaches the disc spooler programs, 
and then attaches a special monitor to allocate the card 
reader to different spooler programs. After rotating parti¬ 
tion priorities, Marvel goes to EOJ. 

PROCESSING 

Input 

Sprint inputs consist of data records loaded to buffer 
storage areas contained in core and/or on disc. 

Process 

Data bound for a unit record device is first loaded to 
disc where it remains until a track is filled. At that time 
the data is loaded to a core buffer which has a unit record 
device associated with it; all print lines are command- 
chained together, and one SVC is issued to print the entire 
buffer. With Sprint the printer and the punch share 
buffers. 

Sprint also permits data bound for different types of 
unit record devices to be intermixed on the same track of 
the same disc. The advantage of having more than one 
type of device sharing the same file is that as blocks are 
written to the file for various devices, they will be likely to 
fall in the same cylinder. This means a reduction in the 
seek time which would be normal when more than one 
spool is being utilized on the same physical disc unit. 
However, when data is being transferred to core for 
output, it must be distributed among the buffers as¬ 
sociated with each device. 


This method can, however, reduce the efficiency of disc 
space utilization because when low-usage spool devices 
are mixed with high-usage spool devices, the low-usage 
device is not operational for some reason. This situation 
causes its records to be temporarily irretrievable. 

Output 

Output can be to card, tape, printer, or disc. If more 
than one printed or punched copy is required, the user 
may designate up to 9,999 copies. 
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EVALUATION 

As spooling programs go, Sprint is not exactly rudimen¬ 
tary. It is not, however, as sophisticated as some of its 
competitors, for example, Software Designs GRASP. 

Sprint, basically, provides most of the spooling capabil¬ 
ities one should need, plus a few very nice features such as 
device address independence, relocating loader, and parti¬ 
tion balancing. The latter feature is worth noting for it 
prohibits high priority programs — especially those with 
well balanced CPU and I/O times — from freezing out 
lower priority jobs. 

Sprint does have one potentially significant drawback; 
it does not support RJE. If your future needs appear to 
lean toward remote job entry, you’d better think twice 
t\efore you buy Sprint. We say think twice because even if 
RJE is in your future, your present needs can be met quite 
nicely with Sprint. 


The users we spoke to agree Sprint meets its specs. No 
real problems have occurred. 


SUPPORT 

The rental price includes installation, training, and doc¬ 
umentation. The vendor supplies object code and operator 
instructions. A combination programmer’s manual and 
installation guide has been prepared and should obviate 
the need for on-site vendor training and installation assist¬ 
ance. Sprint carries no guarantee against source code 
bugs, and maintenance is included in the rental. 

HEADQUARTERS 

Oxford Software Corp. 

511 Main St. 

Fort Lee NJ 07024 
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OVERVIEW 

PAN-DA (Pansophic-Direct Access) is a utility system 
that monitors direct access storage utilization and 
produces status reports showing volume and data set as¬ 
signment and usage statistics. The system works with IBM 
2311, 2314, and 3330 volumes and handles partitioned 
data set (PDS) and ISAM files. 

The PAN-DA system runs on any model of an IBM 
System/360 or 370 under supervision of OS'or OS/VS. It 
requires a minimum of 70K bytes of real storage plus 
direct disc storage or tape for work files. 

PAN-DA is offered on a perpetual license basis, and is 
billed according to the following schedules: $1,800 single 
payment or $ 180 per month for 12 months. Discounts for 
multiple installations are 10 percent per site for two to five 
installations and 25 percent per site for six or more in¬ 
stallations. An unlimited license is available for $9,800. 

Maintenance is free for the first year. Thereafter it is 
available under a yearly contract for $180. 

DESCRIPTION 

PAN-DA is basically a utility system which reads and 
analyzes the volume table of contents (VTOC) from each 
disc pack and produces an analysis of disc space utiliza¬ 
tion. The system neither controls nor manages the DASD 
space, but rather provides easy-to-read reports to allow 
users to determine how well (or poorly) disc space is being 
utilized. These reports are useful for application system 
managers controlling space allocation on discs assigned to 
specific applications or company divisions and for in¬ 
stallation managers controlling system allocations. 

The services PAN-DA offers include: 

• Two report types: Volume and User Group. 

• Comprehensive summaries following each report. 

• Flexibility in report sequence and spacing. 

• Analysis of partitioned data set and indexed sequen¬ 
tial files. 

• Analysis of Panvalet* libraries. 

• Information about each data set— 

(1) Total number of tracks and extents allocated; 
number of tracks used, unused, and available for 
extension (also shown in IBM’s IEHLIST). 

(2) Dead space, which could be recovered through 
reallocation/compression. 

(3) Percentage of allocated space in use. 

(4) Data set characteristics (block size, logical 
record length, data set organization). This is also 
in IEHLIST. 

(5) Indication of whether the data set is cataloged 
(also in IEHLIST). 

• Information about each volume— 

(1) Percentage of available tracks allocated to each 
volume. 

♦Panvalet is a DASD library system also marketed by Pansophic. 


(2) VTOC extent information (also in IEHLIST). 

(3) Total number of dead tracks on each volume 
could be recovered through reallocation/compres¬ 
sion. 

(4) Defective track information. 

(5) Availability of space remaining on each volume 
(also in IEHLIST). 

• Information about each user, including the total 
number of tracks allocated, dead, used, and avail¬ 
able by user group and device type. 

• Facilities to standardize data set names. 

With this information, users may: estimate space 
requirements for new systems; identify overallocated or 
obsolete data sets; spot partitioned data sets or ISAM 
files that are running out of room or whose overflow 
areas are causing unnecessary I/O operations; eliminate 
stray data sets; evaluate future DASD resource 
requirements; and prepare to compress PDS to eliminate 
dead space. 

PROCESSING 

Pansophic provides the JCL needed to define the 
system, which the user in turn may place in the 
PROCLIB. Thus, PAN-DA operates as a separate step, 
which may be placed anywhere in the user’s job stream. 
The JCL includes statements which define the volumes to 
be analyzed (one DD for each volume is required), define 
the data set on which the control card error listing and 
volume or user group report will be written, and define the 
two PAN-DA work files (these may be on tape or disc). 

Although the work files may be assigned to tape, the 
vendor suggests that discs be used to gain maximum ef¬ 
ficiency. When discs are used, the amount of space to be 
assigned to each work file is based on the estimated 
number of format 1 DSCBs to be processed. PAN-DA 
writes blocks 1,400 bytes long, with each block containing 
10 DSCBs. A minimum of 10 blocks must be assigned to 
each of the two work files. 

If ISAM files are being used and User Group reports 
(see “Output") are to be produced, then an additional 
work file must be established. Space allocated for this file 
is in blocks of 140 bytes, allowing three blocks for each 
ISAM file. For ISAM data sets to be evaluated, the follow¬ 
ing conditions must be satisfied: all elements (prime, 
index, and overflow) must be available; the initial load of 
the data set must have been completed; and the DSCBs 
must not contain invalid information. 

PAN-DA also furnishes optional control card 
keywords, which may be used to specify report type and 
sequence; associate a user group with data sets being 
analyzed; and allow high-level indices or fully qualified 
data set names to be associated with the group defined. 
Any number of indices or data set names may be sub¬ 
mitted for each keyword. 

Other optional keywords allow the user to specify the 
sequence of a volume or user group report and sort the 
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report by field, index, or data set name. Users may also in¬ 
dicate, via keywords, that reports be single, double, or 
triple spaced and that only summary information be 
produced. These are all excellent features, and none are 
offered by I EH LIST. 

The final keyword permits PAN-DA to analyze the 
contents of Panvalet libraries. 

Output 

PAN-DA provides two classes of reports: Volume and 
User Group. The Volume report for partitioned data sets 
contains summary data showing: 

• Number of tracks on the device minus alternate 
tracks. This does not include relative track zero. 

• Total number of tracks allocated on the device. 

• Number of tracks allocated to the VTOC on that 
volume. 

• Total tracks on the device minus the sum of 
allocated tracks plus VTOC tracks. 

• Total number of dead tracks on that volume which 
could be recovered by reallocation/compression. 

• Total unused tracks allocated to data sets. 

• Total available tracks plus dead tracks and total 
overallocated tracks. 

• Percentage of tracks on the device that were actually 
used. 

• Number of alternate tracks assigned to replace 
defective primary tracks. 

• Remaining tracks which may be assigned as alter¬ 
nates. 

• Number of extents available for allocation on that 
volume. 

• Number of format labels in the VTOC. 

• Number of data sets currently residing in that vol¬ 
ume. 

From the summary Volume report the user can deter¬ 
mine the number of tracks available on the pack and the 


percentage of utilization. It also indicates the potential 
number of tracks that will be available after reorganiza¬ 
tion or compression. 

For most installations the Volume report will not meet 
all needs since it fails to identify where specific dead 
areas or potential overflows exist. PAN-DA supplies this 
information in detailed reports which show the initial 
allocation of the data set by track, cylinders, blocks, or 
absolute allocation; secondary allocation and quantity of 
the allocation; extents; tracks available; tracks dead; 
tracks allocated and used; and percentage or track 
utilization. 

The User Group reports for partitioned data sets show 
information organized by specific user groups. The 
report fields are primarily the same as those contained in 
the Volume report, except that the User Group report 
does not contain the creation or expiration dates. A 
sample User Group report is shown in Figure 1. 

In the case of ISAM files, Volume reports are 
produced only if all elements reside on the same volume. 
No multivolume evaluation is performed. Multivolume 
evaluation is performed for User Group reports, 
provided a //SYSPAK DD statement is submitted for 
each volume containing an element of the data set. 

The User Group report for ISAM files shows the total 
tracks and extents allocated to all elements of the data 
set (prime, index, and overflow). The prime area line lists 
each volume and contains tracks available, used, and 
allocated. Device type, serial number, and number of ex¬ 
tents are also shown. 

The cylinder overflow line indicates the total number 
of prime tracks available, used, and allocated. The index 
area describes the tracks available, used, and allocated as 
the master or cylinder index area. The overflow area 
shows the tracks available, used, and allocated as an in¬ 
dependent overflow area. The figures include prime 
tracks allocated for cylinder overflow. 
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Figure 1. Pansophic PAN-DA: Sample User Group Report 
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The Volume report for ISAM shows the prime area 
and describes the number of tracks available, used, and 
allocated minus tracks used as cylinder overflow. The 
index area and overflow area are handled in the same 
way as for the User Group report. 

EVALUATION 

Of late, users (and their managers) have been expressing 
a great deal of interest in system resource utilization, since 
you still pay for all that hardware regardless of whether 
you use it or not. To measure utilization, a number of 
good and a few excellent monitors are available. Most, 
however, do not provide the level of statistics needed to 
pinpoint real problem areas. 

PAN-DA is one of the new class of systems that has 
moved beyond the “rough data” league. Like its 
predecessors, it provides the general information upper 
management needs; and, like its contemporaries, it 
provides the detailed technical information required for 
corrective action. 

A logical question when evaluating PAN-DA is, “Why 
buy it; IBM’s IEHLIST utility shows what’s in the 
VTOC?” While this is true, the information provided by 
the IBM utility isn’t as refined as PAN-DA’s. Also, the 
format of IEHLIST is difficult to read — to put it 
euphemistically. 

PAN-DA, however, is not without faults. For example, 
to read the VTOC, each volume must be separately 
mounted and dismounted. This is a chore in cases where 
only a few volumes are involved, and a burden if you’re 


dealing with large numbers. Unfortunately, this is an OS 
problem over which PAN-DA has no control. 

Another PAN-DA shortcoming involves the com¬ 
pleteness of data. Although good current information is 
provided, no statistics are maintained on disc activity. No 
percentage of growth or dynamic growth activity is appar¬ 
ent; rather this must be calculated by the user. Also miss¬ 
ing are counts showing the number of packs analyzed to 
date. It would be quite helpful, too, if the user reports were 
capable of being broken down into subgroups or would 
allow nesting of subgroups. 

In conclusion, PAN-DA represents a large step away 
from the somewhat rough data available through 
IEHLIST, does pinpoint problem areas, and does provide 
very readable reports. PAN-DA could stand a little more 
refinement itself to make it easier to use. 

SUPPORT 

The vendor provides full maintenance for 1 year 
without additional charge. This includes all enhancements 
developed for general distribution. Beyond the first year, 
the user may purchase maintenance on a contract basis. 

Also included in the license fee are installation assist¬ 
ance (if necessary) and two sets of manuals. 

HEADQUARTERS 

Pansophic Systems Inc. 

1301 W 22nd Street 

Oak BrookIL 60521 
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OVERVIEW 

Pan-Sort is a disc sorting package which uses its own 
resource optimization features to perform highly efficient 
sorts. It is compatible with IBM’s SM023 and SM-1, ex¬ 
cept Sort D (OS) and D-Sort (DOS), and supports the same 
JCL and control cards. 

The system operates as a stand-alone sort on an IBM 
System/360 or 370 under DOS, OS, and their virtual 
storage counterparts. It requires its own partition and 
SVC, and it needs a minimum of 12K bytes of main 
storage plus one direct access device for the sorting opera¬ 
tion. Source language is Assembler. 

Pan-Sort is offered on a perpetual license, or it may be 


leased on a yearly or a 

monthly 

basis under the following 

schedule: 




Version 

Perpetual 

($) 

Yr. Rental 

($) 

Mo. Rental 

($) 

DOS 

8,000 

2,000 

200 

OS/VS 

10,000 

3,000 

300 

AM Option (DOS) 

3,000 

1,000 

100 

AM Option (OS/VS) 

5,000 

1,500 

150 


A yearly maintenance fee of $750 for DOS or $1,000 
for OS is charged for perpetual licenses. Maintenance is 
free for rented systems. Multiple installation discounts are 
also offered. There are currently about 25 installations. 

DESCRIPTION 

Pan-Sort is a reentrant, disc sort program which 
handles both positive bias fixed- and variable-length files. 
Maximum record sizes are 13,022 bytes logical and 
13,030 physical when operating on a 3330 disc. Up to 
nine files with 64 control fields (OS) or 32 control fields 
(DOS) can be handled. Each control field may be 256 
bytes long. 

The system employs QTAM for both sort and merge 
and interfaces with IBM 2311, 2314, 3330, and 3340 
discs. It supports rotational position sensing in the DOS 
version and offers COBOL and PL/1 SORT verb compati¬ 
bility. 

With Pan-Sort, the user may choose his own brand of 
efficiency. He may specify that the system run with 
minimum throughput, I/O time, CPU time, or I/O ac¬ 
cesses. 

Pan-Sort’s main thrust is towards economy of resources 
while effecting the fastest sorts possible. Lor example, the 
system does not require that a fixed amount of work space 
be reserved; rather, it looks at the sort work size, considers 
the number of records to be sorted, and reserves that 
amount of space. Also, Pan-Sort employs dynamic core 
management whereby core no longer in use is released for 


use by subsequent phases. The same sort of management is 
applied to disc storage; when a block is read into main 
storage, the vacated disc space is freed and can be used by 
the next block. Thus, the reserved disc space need only be 
slightly larger than the input file size. 

One of the more interesting offerings of Pan-Sort is its 
Access Method (AM) option. To call it an access method 
is somewhat of a misnomer; it is really a sophisticated im¬ 
bedded sort which works with COBOL, PL/1, LOR- 
TRAN, and ASSEMBLER programs. The AM permits 
the user to establish multiple sort parameter lists and build 
multiple sort tables in a single pass. In addition, the sorted 
files can be saved or passed to another program. AM 
requires an additional 5K bytes of main storage plus the 
necessary scratch areas to handle each sort. 

PROCESSING 

Input 

Pan-Sort’s input consists of one or more data cards, 
each of which describes a possible configuration on which 
the sort package will operate. The data cards specify: CPU 
model, operating system version, type of efficiency 
desired, core size, and working device. 

The user must also enter the same sort parameters as 
those required by SM-1 and SM023. The parameters 
include: amount of core available, method for handling 
messages to control listing of output, and devices to be 
used for I/O and work. 

Process 

Pan-Sort carries out its processing in four phases. 
During the initial phase, it processes the control state¬ 
ments and establishes relationships between the run 
parameters and the operating system. Based on the system 
resources and file size, Pan-Sort calculates the optimum 
block size for disc work space needed to achieve the 
smallest number of I/O’s. 

Two sorts are then carried out. The initial sort ini¬ 
tializes system components and assigns them. It then 
orders the records into sorted sequences and calls the 
work and input files. The second sort, called the external 
sort, is run only if the number of sequences resulting from 
the initial sort exceeds the available merge order. In this 
case, shorter strings are merged into longer, more efficient 
strings. 

Pan-Sort employs cascade and parallel sorting tech¬ 
niques. With the former, all data is written to a temporary 
sort file. After sorting, one record at a time is read from 
the temporary file into an output file. With parallel 
sorting, the entire file can be passed at one time and sorted 
into various sequences. 

If multiple sorts are desired, the user may employ the 
AM option, an imbedded sort which runs with COBOL, 
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PL/1, FOR I RAN and Assembler programs. When using 
AM, the user must establish sort parameters by specifying 
the DD name for the associated work data set, the core 
frame allocated to the sort, and the sort control fields. AM 
runs with either sort and permits the building of multiple 
sort tables in a single pass. It requires no intermediate 
files, and each sort file needs only one extent. 

The final Pan-Sort operation is the merge, and it is ex¬ 
ecuted for both sort and merge operations. Its operation is 
typical of a merge program: it initializes system compo¬ 
nents and assigns them, and it merges input files or input 
sequences to form a single sorted output. 

EVALUATION 

Pan-Sort is an example of one of the better pieces of 
software to come out of Europe. Written by Computer As¬ 
sociates of Geneva, it has been marketed for a number of 
years in Europe under the name CA-Sort. It has been 
fairly successful there and should enjoy equal success in 
the United States. 

Pan-Sort’s advantages are its speed and efficiency. Pan- 
sophic claims that it is 50 percent faster than its IBM 
counterparts and, under certain circumstances, it proba¬ 
bly is. Users, however, report figures like 25 to 30 percent. 
The efficiency of the system is reflected in the way it 
manages resources. Its dynamic management of core and 
disc, for example, cuts overhead significantly. 

The AM option is also a Pan-Sort plus. With it, mul¬ 
tiple sort parameters can be specified and sort tables built 
in a single pass. This adds speed and flexibility to the 
sorting operation. 


Pan-Sort does have a few shortcomings, aside from the 
fact that it can’t perform tape sorts. Paradoxically, its 
greatest drawback arises from the fact that block replace¬ 
ment is performed as part of the dynamic management of 
disc space. Consequently, normal checkpointing is impos¬ 
sible. When we questioned the vendor about this, it was 
acknowledged that normal checkpointing couldn’t be 
done, but it was also pointed out that enough exits were 
built into Pan-Sort to allow the user to take his own check¬ 
points. This may not be the most efficient (or safest) way 
to handle this, but we believe that it’s better than nothing. 

If you’re planning to run under VS and wish to employ 
page fixing, you can’t do it. The merits of page fixing can 
be hotly argued. Some will argue that it freezes out jobs 
and, thus, degrades overall performance. Supporters will 
quickly point out that page fixing will increase throughput 
by blocking out I/O’s. Both are correct. We believe, how¬ 
ever, that the user should have the option of invoking page 
fixing and EXCP translation. 

SUPPORT 

Pansophic provides free maintenance for the first year 
and contract maintenance for perpetual license users 
thereafter. Maintenance for renters is free for the life of 
the installation. The vendor claims that no training is nec¬ 
essary for the simple version; however, half of a day is 
needed if AM is ordered. This training is free. 

HEADQUARTERS 

Pansophic Systems Incorporated 

1301 West 22nd Street 
-Oak Brook IL 60521 
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OVERVIEW 

Disclose is a utility package that provides a set of con¬ 
venient survey and summary reports of direct access and 
tape volume utilization, data set organization, and catalog 
structure. It can be used for IBM 2301; 2302; 2303; 2305; 
2311; 2314; 2319; 2321; 3330 Models 1, 2, and 11; and 
3340 direct access devices, plus any non-I BM devices that 
conform to the capacity specifications of the corollary 
IBM unit. 

The system runs on any IBM 360/370 under OS/MVT, 
MFT, VS1, and VS2 Release 1. It can also operate under 
VS2 Release 2 if authorized under the Authorized Pro¬ 
gram Facility and PCP with proper print file 
modifications. 

Main storage required for Disclose is variable. The 
exact region size is dependent on several operational con¬ 
ditions, such as the number of data sets to be surveyed and 
the number of extents contained in the largest single 
VTOC. The two operational programs, Survey Program 
and Directory Program, require 16K and 30K of program 
space, respectively. Each also requires 12K of buffer 
space for SYSPRINT, SYSREPT, and SYSUT1. In addi¬ 
tion, the Survey Program needs VTOC input buffer space 
of 156 bytes per DSCB on one track and a VTOC storage 
area of 250 bytes per data set; the Directory program 
needs a sort work space of not less than 40K bytes nor 
more than 256K. 

Disclose is sold for use at a specific installation. Its 
price is $725 for a package with the optional Catalog Fea¬ 
ture, $450 without. The latter can be upgraded to include 
catalog support at a cost of $325. The delivered package 
includes a tape containing the object and source programs 
plus required job control procedures and all necessary 
documentation. It carries a 30-day warranty during which 
period the package can be returned for full credit. 

DESCRIPTION 

Disclose is a utility system that provides the user with 
variously formatted reports for both a single volume and a 
set of volumes. It lists various information categories rela¬ 
tive to the allocation and utilization of auxiliary storage, 
data set organization and characteristics, catalog and 
VTOC structures, and free space in the case of direct 
access units. The package comprises three basic programs: 
the Survey Program (DSC001) and the Directory Pro¬ 
gram (DSC002), both of which perform separate analysis 
and reporting functions, and a Control Program 
(DSCLINK). DSC001 and DSC002 operate either as sep¬ 
arate job steps or as a single job step controlled by 
DSCLINK facilities. 

DSC001 accepts input from the volume units, reads the 
VTOC and catalog, creates a Volume Information File 
from the VTOC and catalog data, and optionally produces 
a set of Volume Reports for each volume surveyed. 


DSC002 uses the data structured in the Volume Infor¬ 
mation File. It produces a set of System Directories that 
present a consolidated view of the attributes and charac¬ 
teristics of the set of volume identified in the VIF 

The Volume Reports produced by DSC001 fall into six 
categories — four VTOC related, two catalog related. 
Each report may be generated optionally. The set of 
reports includes: 

• Data Set Report, which lists each data set by name, 
its creation data, DCB attributes, and space used. 

• Free Space Map, which lists all free unassigned 
tracks. 

• Track Allocation Map, which lists track usage both 
assigned and free by extent. 

• Volume Summary Report, which is listed only if 
none of the three preceding reports is requested, 
summarizes a surveyed volume’s characteristics. 

• Catalog Report, which lists all data set names, 
aliases, generation data group indices, CVOL point¬ 
ers, and unused indices in the catalog. 

• Catalog Summary Report, which lists the size and 
location of the catalog data set, its entries, and its 
total space requirements. 

The System Directories produced by DSC002 each 
contain combined data from VTOCs and catalogs en¬ 
tered into the DSC001 -generated Volume Information 
File. Each may be optionally limited to specific classes 
of data sets. The set of reports is: 

• System Data Set Directory, which produces a 
comprehensive ordered, data set name list for all 
surveyed catalogs and VTOCs. 

• Tape Data Set Directory, which produces a list or¬ 
dered by data set name for all data sets identified in 
the surveyed tape catalogs. 

• Tape Volume Directory, which lists magnetic tape 
volumes by catalog entry, ordered either by tape 
volume serial number or serial number within data 
set group. 

Data provided in the various reports presents the user 
with a relatively complete view of current auxiliary 
storage utilization in both absolute terms and as percent¬ 
age values. Additionally, the data set information listing 
provides sufficient data to: anticipate potential problem 
conditions, such as inadequate or unnecessarily frag¬ 
mented overflow areas; evaluate future DASD 
requirements; and establish criteria for ‘ garbage collec¬ 
tion” and data set compression and elimination. 

PROCESSING 

The delivered Disclose tape includes JCL procedures 
for: executing the operational programs; link-editing the 
object modules and entering them into a program library; 
and retrieving the source modules and cataloging them 
into a source library. The JCL control statements 
provided by the user supply the definitions for the mes¬ 
sage listing, and produce report print data sets, an optional 
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sort message data set, library identifications for all 
required programs (Disclose programs and the Sort for 
DSC002), a Volume Information File sequential data set, 
and identification of the volumes and catalogs to be 
surveyed. 

The two main operational programs are invoked 
through the cataloged JCL procedures DSCVY and 
DSCDIR. Both programs may be run as separate job steps 
or may be invoked as a single job step through a supplied 
JCL procedure, DSC 12. 

DSC001, which produces volume-related reports and 
creates the Volume Information File used by DSC002, 
can be executed with a variety of optional run parameters 
supplied by keywords. Typical options include the report 
categories to be produced, data set groups to be listed, and 
page line counts. Similarly, DSC002 allows parameter op¬ 
tions for limiting directory output to selected data set 
groups and for controlling details of directory format and 
content. 

The Volume Information File may be written to either 
a direct access or standard-labeled tape device. It is 
written in 164-byte-length blocked records. As successive 
runs of DSC001 may use a variety of storage units with 
unequal blocking factors declared, DSC002 has the facili¬ 
ty to concatenate various file generations in order to 
produce its directories. 

Output 

Disclose produces two general classes of reports: the 
Volume Reports, a group of volume-related reports listing 
volume and catalog information on a per-volume basis, 
and the System Directories, a group of system directories 
that presents consolidated reports on the set of volumes 
surveyed. Most of the reports include several fields, which 
can be optionally generated through JCL keyword nota¬ 
tion. The Volume Reports comprise six separate report 
formats: the VTOC Summary, Data Set Report, Free Map 
Space Report, Track Allocation Report, Catalog Report, 
and Catalog Summary. 

Volume Reports 

VTOC Summary Report. This report describes vol¬ 
ume characteristics and summarizes volume track 
utilization. It includes information on: 

• Number of free tracks. 

• Number of free full cylinders. 

• Number of extents into which space is divided. 

• Percentage of volume allocated to data sets. 

• Percentage of volume free. 

• Percentage of volume neither allocated to data sets 
nor accounted for as free space. 

• Number of DSCBs in the VTOC. 

• Number of tracks and full cylinders in each of the 
five largest extents. 

• Number of data sets residing on that volume. 

• Total number of DSCBs in the VTOC. 


• Address of first and last track of VTOC. 

• Number of alternate tracks in use. 

• Next available alternate track. 

• Volume serial number. 

• Device type. 

• Number of tracks, exclusive of alternates on 
volume. 

• Number of cylinders excluding alternate tracks. 

• Number of tracks in each cylinder. 

• Length of track in bytes. 

• Number of DSCBs on a single track in VTOC. 

• Number of partitioned data set directory blocks that 
can reside on a single track. 

• Also identifies the SYSRES volume and may 
include various information/error messages. 

Data Set Report. This report produces an alphabeti¬ 
cally ordered list of a volume’s data sets and their char¬ 
acteristics. It includes: 

• Complete name of data set. 

• Volume serial number of the first volume on which 
the data set was created. 

• Data set sequence number. 

• Data set security. 

• Creation and expiration dates. 

• Data set organization (unspecified, ISAM, physical 
sequential, partitioned, DAM, VSAM, or invalid). 

• A notation if the data set is unmovable. 

• Record format (fixed, variable, blocked, standard or 
spanned, ANSI control character, machine control 
character, track overflow). 

• Logical record length. 

• Length of physical key. 

• Block size. 

• Number of tracks allocated to data set. 

• Number of tracks used (sequential and partitioned 
data sets only). 

• Number of extents used for the data set. 

• Secondary allocation quantity (tracks, cylinders, 
blocks, absolute track address). 

• An optional hex dump of all VTOC DSCBs. 

Free Space Map. The Free Space Map indicates the 
location and size of free extents ordered by physical 
track address. It includes: 

• Decimal number of first track in the extent. 

• Physical address of the first track in the extent. 

• Physical address of the last track in the extent. 

• Number of tracks in the extent. 

• Number of full cylinders in the extent. 

Track Allocation Map. This report lists contiguous 
track extents by physical address indicating location, 
size, and usage of the extent. It includes: 

• Decimal number of the first track in the extent. 

• Physical address of the first track in the extent. 

• Decimal number of the last track in the extent. 

• Physical address of the last track in the extent. 

• Number of tracks in the extent. 

• Number of full cylinders in the extent. 

• The sequence number of the extent within a dataset. 
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• Extent type, indicated as — 

(1) Extent is on cylinder boundaries. 

(2) User label track. 

(3) Shared-cylinder extent. 

(4) Indexed sequential overflow extent. 

(5) Indexed sequential index area. All other cases. 

• The name of the dataset or a description of the 
extent usage if it is not allocated to a data set,viz. — 

(1) VOLUME LABEL. 

(2) VOLUME TABLE OF CONTENTS. 

(3) FREE. 

» The number of missing tracks, extent overlap, and 
invalid extents. 

Catalog Report. This report lists catalog contents 
ordered alphabetically by data set name. It produces 
various categories of information. 

• For each data set, it indicates: 

(1) Complete name. 

(2) Volume serial number. 

(3) bevice type. 

(4) Data set position number (tape). 

• For the oldest number of a generation data group: 

(1) Maximum number in the index at one time. 

(2) Current number of data sets in the index. 

(3) A notation indicating that data sets are deleted 
when their index entries are removed. 

(4) A notation indicating that all data sets are 
removed from the index when it overflows. 

• For control volume pointers: 

(1) Name of first-level index. 

(2) Volume SN of second volume. 

(3) Device type of second volume. 

• General: 

(1) Aliases and associated indexes. 

(2) Unused indexes. 

(3) Error and information messages. 

(4) A default hex dump of the catalog. 

Catalog Summary. The summary lists the attributes 
of the catalog data set and includes: 

• Number of blocks in use and percentage of total. 

• Number of blocks not in use and their percentage of 
total. 

• Number of blocks in the catalog data set. 

• Number of extents in the catalog data set. 

• Number of units to be added if the catalog needs 
more space. 

• Device type. 

• Number of catalog blocks on one track. 

• Number of data set names in the catalog. 

• Number of generation data group indexes. 

• Number of alias entries. 

• Number of control volume pointers. 

• Number of unused index names. 

• Number of generation data group indexes referring 
to no data set. 

• Number of first-level index names. 

• Number of blocks containing the volume index. 

• Number of noncontiguous groups of blocks in the 
volume index. 

• Physical location and size of each extent of the 
catalog data set. 


System Directories 

The System Directory reports are produced from all 
data generated for the Volume Information File of 
Disclose. Each of the directories may be limited to 
selected data set groups and may contain several statistical 
sub- and grand-total summaries for various data set at¬ 
tributes. Each directory may be preceded by a Catalog 
Contents Summary. It identifies: 

• Volume SN. 

• Device type. 

• Date and time catalog survey was made. 

• Number of complete names in the catalog. 

• Number of 256-byte blocks in the catalog. 

• Number of extents in the catalog. 

• Percentage of catalog blocks in use. 

• Identification of the SYSRES volume. 

• Appropriate error counts. 

Three directories are provided. One is a summary of 
all volume types. The remaining two are tape oriented. 

System Data Set Directory. This report combines 
information from one or more Volume Information 
Files and presents it in data set name sequence within 
data set group. It is preceded by a Direct Access VTOC 
Summary that includes for each DA volume surveyed: 

• Volume SN. 

• Device type. 

• Date and time survey was made. 

• Number of data sets on the volume. 

• Percentage of tracks allocated to data sets. 

• Number of tracks available. 

• Number of full cylinders available. 

• Number of extents used for free tracks. 

• Percentage of tracks available. 

• Percentage of tracks missing. 

• A SYSRES indicator. 

• An indication of extent overlap. 

The System Data Set Directory itself lists for all found 
datasets: 

• Complete name of data set. 

• Volume SN. 

• Device type. 

• Data set sequence number. 

• Data set position number (tape). 

• An indication of correct cataloging of DA data sets. 

• An indication of multiple cataloging of first-level 
indexes. 

• Creation and expiration dates. 

• Data set security. 

• Data set organization. 

• Record format, logical record length, and block 
length. 

• Number of tracks allocated to the data set. 

• Number of tracks actually in use (sequential and 
partioned data sets only). 

• Number of extents. 

• Secondary allocation quantity and type of unit. 

• Volume SN containing first-level index. 
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• Control volume pointers. 

• Index aliases. 

• Generation data groups. 

• Unused indexes. 

Tape Data Set Directory. This report combines in¬ 
formation from all cataloged tape data sets. It includes 
for each data set: 

• Complete name. 

• Data set sequence number. 

• Volume SN. 

• Device type. 

• Data set position number. 

Tape Volume Directory. This directory lists all 
tape volumes containing cataloged data sets. It is ordered 
by volume SN within data set group and includes: 

• Volume SN. 

• Device type. 

• Data set position. 

• Data set name. 

• Data set sequence number. 


EVALUATION 

The Disclose package offers the user a relatively 
painless and inexpensive method of monitoring one of the 
most important resources, if not the most important 
resource, in an installation: the data set collection. The 
package provides the user with all the significant informa¬ 
tion (with one or two major exceptions) needed in order to 
exercise strict administrative control over volume usage. 
The emphasis is, of course, on administrative controls 
because Disclose does not perform any ‘volume manage¬ 
ment” functions. It is only a reporting process, albeit a 
highly convenient one. 


The major shortcoming of the package is the lack of 
numbers other than those gross track assigned for ISAM, 
DAM, and VSAM organized data sets: All tracks assigned 
to such organizations are considered to be used. A second¬ 
ary analysis is required if the current space available is 
needed by the user. However, Programart has indicated 
that this problem is in the process of being corrected. Fa¬ 
cilities for providing ISAM, DAM, and VSAM usage 
factors will be available in a future release of Disclose. 

An additional change that would seem to be a logical 
extension of the package is a simplified “automatic func¬ 
tion,” which would permit on-line or batch housekeeping 
of both volumes and catalogs through the data already 
compiled in Disclose’s Volume Information File. All the 
required data is there — data set names, volume SNs, 
CVOL pointers, etc., waiting to be used through a 
simplified reference scheme to create the required control 
cards. Although this has apparently not been considered 
by Programart, it appears to be a relatively simple task 
and one that would enhance the usability of the package 
immeasurably. 

Of the several users interviewed during the course of 
preparing this report, not one was unhappy with the 
package except for the ISAM/DAM/VSAM problem just 
mentioned. 

All felt that the various reports, incidental statistics, 
and error/information messages were produced in a highly 
convenient and usable form. And, last but not at all least, 
the price of Disclose is certainly right. 

HEADQUARTERS 

Programart Corporation 

133 Mount Auburn Street 

Cambridge MA 02138 
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OVERVIEW 

Rockwell International’s Automatic Restart System 
allows users running multistep jobs to start them at the 
point of failure without requiring programmer analyst 
time or JCL coding. 

It is written in Assembler language and runs on any 
IBM System 360 or 370 under OS. It may be used with all 
versions of OS, including M VT, MFT, ASP, HASP, etc. 

The one-time lease price for a single computer center is 
$2,000. Additional sites may acquire the system for 
$ 1,000 for each location. 

This package was first released in the late 1960s and has 
been purchased by six organizations outside of Rockwell. 

DESCRIPTION 

Restart enables the user to restart any multistep job 
that fails to run to completion automatically, without 
analysis of the cause of the failure, without alteration of 
the JCL, and without re-execution of successfully 
completed steps. In the case of a job failure, the system 
operator simply reloads the job's reader with the JCL. 
The package then determines where the failure occurred, 
and at what step the job should be restarted. All success¬ 
fully completed job steps are bypassed, and execution is 
resumed at the proper step. 

This system applies to jobs that are terminated 
because of unavailable SYSDA space, hardware failure, 
system software failure, power failure, airconditioning 
failure or other abnormal job endings (ABENDS). Its 
operation depends only upon the existence of a system 
catalog and the ability to test condition codes set by pre¬ 
ceding job steps. 

Restart is installed by the programmer as the first step 
of a multistep job. As each step is successfully 
completed, a step indicator, a dummy data set name 
called a “pmm 61 '’” is stored in the system catalog. Simul¬ 
taneously, the pointer put in by any preceding step is 
removed. 

If a job fails in any step. Restart finds the last pointer 
cataloged, and resumes execution at one of the 
following: 

• the step that failed; 

• a step selected at restart time; or 

• a step preselected by the user. 

When the final step is completed, the last pointer is 
removed from the catalog. 

Manual override is provided for at execution time, so 
that the operator may test JCL, take specific corrective 
action, or select a particular step for restart. A number 
of messages are provided on SYSOUT, indicating 
normal operation, use of options, status errors, etc. 


A special STOP is incorporated as part of Restart to 
prevent restarting of any step which could adversely af¬ 
fect an on-line file, and also to prevent any restart, 
should a job terminate in a step that updates an on-line 
file, until that file has been restored. 

PROCESSING 

Restart is installed as the first step in the multistep job. 
When a normal production run is started. Restart recog¬ 
nizes that it is a normal run, not a restart, and returns 
control to OS so that processing may begin on a step-by- 
step basis. As each job step is successfully completed, a 
DD statement is used to put a dummy DSNAME (point¬ 
er) into the system catalog. At the same time, the pointer 
DSNAME, entered at the completion of the preceding 
step, is removed. Thus, there is only a single pointer in 
the catalog at any given time during execution. 

When the job abends and is restarted, the program 
brings in a user-defined control data set from disc. This 
data set contains a table of step names and associated 
pointer names, and consists of the following four data 
records: 

• The PROCEDURE record, which enables the pro¬ 
gram to determine whether the job is an initial run 
or a restart. 

• STEP records, which are used by the program to de¬ 
termine the condition code to be generated in the 
case of a restart. 

• STOP records, which enable the program to termi¬ 
nate processing, if certain DSNAMES are found to 
be cataloged. 

• SCRATCH records, which specify the data set 
names to be scratched and uncataloged prior to 
restarting. 

Restart searches the system catalog for the job pointer 
names^ starting with the first entry in the table. When a 
pointer is found, RESTART sets its condition code to a 
predetermined value and returns control to OS. 

The EXEC statement of each job step contains a test 
of the condition code which is set by Restart. Success¬ 
fully completed steps are bypassed and the job is re¬ 
started at the desired step. 

To properly implement this system, the user must 
analyze his production system, determine where to re¬ 
start the job when it fails at any step, modify the JCL to 
accomplish this restart, test the modified system, and then 
document it. To accomplish this, the following informa¬ 
tion is required: 

• a block diagram or flowchart of the job. 

• the restart point for each step when it abends. 

• all temporary files with their names and disposition 
parameters. 

• identification of steps that update files in place, and 
need for STOP codes. 

• unique pointer names selected by the user. 

• a list of all areas affected by OS failure and instruc¬ 
tions for handling. 
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• the job schedule. 

• the control data set layout. 

These items should be available in any case; hence, the 
Restart system performs as a good documentation tool. 

EVALUATION 

Restart performs a very necessary function, especially 
in data centers running multiple multistep jobs on sever¬ 
al partitions of one machine, or with several machines at 
the same time. One user to whom we spoke noted that, 
by using this system, the burden of successful job execu¬ 
tion was placed on the programmer and analyst and was 
removed from the operator, which meant, to this user, 
that less sophisticated operators were required. It was the 
rule in his shop that all production jobs must implement 
the Restart system as part of their framework. Since ap¬ 
proximately 3,000 jobs were processed by this center, the 
necessity for this edict is evident. 

Another user organization characterized his system as 
“super," but admitted that they had enhanced it to notify 


the operator when an abends had occurred. This was 
especially critical when running jobs under multiple 
partitions. 

No one to whom we spoke had discovered any system 
bugs, even after several years of daily usage. 

SUPPORT 

The purchase price includes the source code and a 
users’ manual with full installation instructions. The 
system is warranted for 90 days. 


HEADQUARTERS 

Rockwell International 
Information Systems Department 
2201 Seal Beach Boulevard 
P.O. Box 2515 
Seal Beach CA 90740 
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OVERVIEW 

FMAINT is a library utility for DOS and DOS/VS 
which replaces IBM’s MAINT program. The package 
operates in a multiprogramming environment and does 
not require the partitions to be shut down during library 
condensing, as is the case with MAINT under DOS. It 
also supports inputs from tape or disc of 80- or 81-byte 
records (or any multiple of 80 up to a block size of 1,600 
bytes) and can read directly from SYSLNK. The vendor 
claims that the system is between five to ten times faster 
than the IBM product. 

FMAINT operates on any IBM System/360 or 370 run¬ 
ning under DOS (up to Release 26.2) or DOS/VS (Re¬ 
lease 1 29 and above). It is link edited into the core image 
library and operates in any partition with 44K bytes of 
main storage. Discs supported include the IBM 2311, 
2314, 3330, and 3340 (or equivalent). 

The system is offered on a lease basis only, for $ 1 50 per 
month. There are currently about 30 users. 

DESCRIPTION 

FMAINT and MAINT share many functional capabili¬ 
ties in that they both catalog, update, delete, rename, and 
condense entries in the DOS and DOS/VS system 
libraries. That’s where the similarity ends, however, for 
FMAINT does much more and, according to the vendor, 
is five to ten times faster than the IBM product. 1 " 

The expanded capabilities offered by FMAINT elimi¬ 
nate a number of shortcomings inherent in the IBM utili¬ 
ty. For example, with MAINT all operations under DOS 
must be halted in the foreground partitions while the core 
image and private libraries are being condensed in the 
background. FMAINT condenses in any partition and 
permits the other partitions to continue processing. It 
does, of course, prohibit jobs operating in those partitions 
from accessing the libraries that are being condensed; a 
library cannot be modified if it is being used by a system 
task in any other partition. Condenses of the same core 
image library can only be done in the background parti¬ 
tion. 

We should point out that IBM’s DOS/VS does not 
require that all partitions be shut down during con¬ 
densing, provided that private libraries are assigned to 
those partitions. 

FMAINT also logically extends the MAINT ALT op¬ 
tion to allow the user to delete entries having any number 


*FMAINT is downward compatible with MAINT and performs all of 
MAINT’s functions. 


of first characters in common. In addition, FMAINT 
permits the user to designate that the input be read direct¬ 
ly from SYSLNK (provided you have enough space, of 
course) by invoking the DOS CATAL option. This 
permits cataloging directly from SYSLNK and is ideally 
suited to installations which must maintain object decks in 
the form of private relocatable libraries. 

EVALUATION 

FMAINT’s strong suite, in our opinion, is not so much 
its operational capabilities, but its speed. 

No, we don’t dispute the value of not having to shut 
down all partitions when condensing libraries, but this 
problem doesn’t exist with DOS/VS, and FMAINT 
doesn’t work with any DOS Release above 26.2. 

The ability to catalog directly from SYSLNK is also an 
excellent feature; it does eliminate a separate run to get 
relocatable libraries. But again, many people wouldn't 
buy FMAINT just to get this. 

Some users might buy FMAINT to get the extended 
ALL option, however, for this increases the speed by 
which deletes are made. 

Most ultimate users will probably buy FMAINT to get 
its library condensing speed, for this we feel is FMAINT’s 
greatest asset, and judging from user comments, they 
think so too. We discussed the system with a number of 
them, and they all talked enthusiastically about the great 
speed of FMAINT. Yes, the other features were useful 
and did work quite well, but speed is what they wanted 
to talk about. Such comments as, “What used to take an 
hour now takes only a few minutes,” were typical. 

So, if you find the speed of MAINT too slow, FMAINT 
may be a fast way out. 

SUPPORT 

The vendor supplies FMAINT as one complete job 
ready for link editing. Total installation time is stated to 
be only a few seconds. Software Design also supplies full 
documentation and fully warrants the system for the life 
of the installation. 

HEADQUARTERS 

Software Design, Inc. 

880 Mitten Road 

Burlingame CA 94101 
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GENERAL 

GRASP is an automatic spooling system for 
the IBM 360 which operates asynchronously with 
problem programs, resides in a foreground par¬ 
tition, and uses its own supervisor. It handles 
local and remote batch jobs in multiprocessing 
mode. 

The system runs on IBM 360 and 370 (DOS) 
and up with a minimum of 32K bytes of main 
core storage and requires a minimum of 6K bytes 
for its partition, plus at least 20 cylinders of a 
Model 2311, 2314, or 3330 Disk Drive of auxiliary 
storage. Source language is BAL. 

Leases are $300 a month for the basic version 
and $630 a month for the extended version. 


PACKAGE DESCRIPTION 

Spooling is a technique that has been used for 
some time to decrease problem program execu¬ 
tion time by intercepting supervisor calls (SVCs) 
for unit record devices and placing the output data 
on a magnetic storage device. After the problem 
program runs to completion, the data is retrieved 
from storage and printed. Quite simple? Yes. 
But also quite costly in auxiliary storage space, 
the amount of time required to ultimately print 
the data, and the overhead incurred by having 
printers and punches sitting idle while the data is 
being spooled. In fact, conventional spooling is 
so time consuming, some packages using it fail 
to mention print times in performance data. 

To counter conventional spooling deficiencies, 
a number of spooling packages have emerged 
recently. These systems generally use the same 
techniques as conventional spooling to transfer 
record data to and from auxiliary storage but 
differ in the way 1/O commands are handled and 
the way records are sorted. Many of the newer 
systems either use their own supervisor or mod¬ 
ify the host system supervisor. GRASP uses its 
own supervisor. 

GRASP, one of the older spooling packages 
(introduced in 1968), is a combination spooling 
and buffering system with additional system con¬ 
trol and monitoring features that are seldom in¬ 
cluded in this type of package. Its program re¬ 
quires between 6K to 10K bytes of main core and 
resides in a foreground partition; in operation it 
buffers and/or spools all I/O to or from readers, 
printers, and punches under its control to back¬ 
ground partitions or disc storage. Extended 
GRASP supports any type of printer, card reader, 
card punch, card reader/punch, paper tape 
reader, or magnetic cartridge reader in any 


desired number and combination. In addition, 
pseudo devices may be defined to simulate addi¬ 
tional unit records. Each spool file may be as¬ 
sociated with as many spoolable devices as 
desired. 

A principal feature of GRASP is its ability to 
output data to a unit record device while the 
problem program is still executing. This is pos¬ 
sible due to the way the GRASP supervisor han¬ 
dles I/O interrupts. The supervisor itself re¬ 
sides in a high-core foreground partition, thus 
making it appear as though it were a fourth DOS 
partition. It in no way interferes with the host 
supervisor, but rather works in conjunction with 
it. No changes to the problem programs are re¬ 
quired either. 

In operation, the problem program issues 
supervisor calls (SVCs) in the usual manner, 
and these calls are routinely analyzed by the 
host supervisor. After determining which I/O 
device should receive the data, a normal start 
I/O command is issued. (A start I/O instruction 
activates an I/O channel and also indicates by 
address which I/O device is to receive the data.) 
It is at this point the GRASP supervisor comes 
into operation. When the GRASP program is 
being specified for a particular application, a 
phantom address is associated with each device 
address being used. Upon issue of this address 
by the start I/O, the GRASP supervisor inter¬ 
cepts it and in turn brariches it to the phantom 
address. 

The phantom address has a particular buffer 
associated with it. Transfer of data to the buffer 
is accomplished through GRASP-generated chan¬ 
nel command words. To keep the system in the 
proper state during this operation, GRASP issues 
a modified PSW. After the data has been trans¬ 
ferred, the old PSW is restored. When the buffer 
is full, its contents are sent to the appropriate 
unit record device. 

The system offers a number of noteworthy 
features. For example, GRASP provides ac¬ 
counting reports with the expected information 
on numbers of cards read, cards punched, lines 
and pages printed, and job times. However, 
more sophisticated information is gathered about 
each job (or job step if desired), such as data on 
operator efficiency, CPU utilization, interparti¬ 
tion interference, counts of phase loads, amount 
of core used, I/O counts on all active SYS units, 
and so on. In addition, the user may gain control 
at several points (own-code hooks) so that details 
such as department code or cost code may be 
recorded. Cumulative records of this type can 
also be built up on tape or disc for periodic 
analysis. 
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GRASP also provides a program relocatability 
feature through its resident program loader 0 With 
it, all user programs, no matter in which lan¬ 
guage they are written, are executable in any par¬ 
tition. Programs reside in private load libraries 
in a form that allows considerable saving of space 
compared with core image library format. 

Remote terminals are supported precisely as 
if they were local card readers/printers/punches. 
Total core requirement for GRASP with RJE is 
6K plus 2K per spooled device (local or remote). 
Devices supported as remote terminals include 
IBM 2770, 2780, System/360 Model 20, System/ 
360 Models 25 and up, and System/3. 

GRASP enables spooling to tape concurrently 
with or instead of its normal disc buffering/ 
spooling. This facility provides backup for large 
reports, as well as flexibility in scheduling where 
and when a large report should be printed. 

If desired, GRASP runs in an independent par¬ 
tition. The package will also function with up to 
8 subtasks in separate partitions in a multitasking 
environment. 

Automatic job scheduling is also a standard 
feature. In this case the system automatically 
selects from its spooled-in streams the job of 
highest priority, whether submitted locally or 
through a remote terminal. The selected job is 
dispatched into the first available partition; re¬ 
location is performed; device-type assignments 
are resolved; and the operator is informed of 
job setup. Users can restrict certain jobs to 
designated partitions.. 

Dynamic device addressing permits the user 
to make assignments to a device type, leaving 
the selection of the specific device to GRASP. 

This permits more efficient use of a smaller 
number of peripherals serving multiple partitions. 

Two other notable features of GRASP that were 
not part of the original system are partition bal¬ 
ancing and transient code retention. With parti¬ 
tion balancing the system continually monitors 
the relative CPU-boundness of processing par¬ 
titions and dynamically alters the partition prior¬ 
ities to attain maximum throughput. This is an 
excellent feature. Partition balancing itself is a 
relatively new concept to DOS but is not restricted 
to GRASP. In essence, the balancing is done to 
prohibit both I/O-bound and CPU-bound jobs from 
monopolizing the machine. The net effect is that 
high priority ’’machine eating” jobs won’t be able 
to freeze out lower priority jobs. 


With transient code retention, GRASP holds 
a stack of the most commonly used transients in 
its partition and moves them to the transient area 
for execution when requested. This results in 
large savings, especially for ISAM users or in¬ 
stallations running a large number of short jobs. 

GRASP also provides procedure libraries, 
wherein procedures may be cataloged once and 
extracted for repeated use. This capability is 
useful for controlling, changing, and protecting 
run decks. 

An automatic paper alignment feature allows 
stationery changes and controls lining-up re¬ 
quirements, even for programs requiring several 
switches of paper in mid-execution. A backspace 
command allows reprinting of lines lost due to 
paper wrecks. 

GRASP accommodates IBM 1400 Series work 
under control of any of the DOS emulator pro¬ 
grams. No alterations are required to these 
programs. 

The basic version of GRASP is available for 
one of the following configurations: one printer 
only; one printer and one punch; one printer and 
one card reader; or one printer, one reader, and 
one punch. Options such as accounting routines, 
attached subtasks, self-relocating linkage editor 
and load routines, remote job entry support, and 
simultaneous printer tape output are available. 

As of this writing, GRASP has approximately 
300 users; we had an opportunity to talk to a few 
to gain their impression of the system. They 
were extremely enthusiastic about GRASP and its 
vendor. The package, according to them, works 
as advertised and has resulted in considerable 
time savings. We only heard one complaint about 
GRASP’S operation, which was that you cannot 
pocket select on a reader if spooling is being 
used. GRASP, however, does offer the capability 
to close off the reader from the spooling program, 
thus permitting it to run under normal DOS. 

Input . System inputs consist of the I/O re¬ 
quests intercepted from the host operating sys¬ 
tem, any user own-coded routines, and the actual 
data to be output. 

Process . The data bound for a unit record 
device is first loaded into a designated buffer 
area, which has a particular device associated 
with it. As soon as the buffer is fully loaded, a 
GRASP channel command word is issued allowing 
the output of data to that device. If the speed of 
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the output device is too slow to handle the buffer 
(which is often the case), the data overflows to a 
specified disc. When the buffer completely emp¬ 
ties, the disc loads it with the next print lines. 

A typical buffer can hold between 15 to 40 such 
lines. 

Output . Output may be to card, tape, printer, 
or disc. If more than one printed copy is re¬ 
quired, the user may designate any number up to 
99. 

FEES AND SUPPORT 

A one-time fee plus per diem is levied to in¬ 
stall the package and train user personnel; pack¬ 
age cost includes a lifetime guarantee against 
source code bugs. 

Installation. About one-half man-day is con¬ 
sidered adequate to tailor the system to the par¬ 
ticular application and install it. 


Training . Formal instruction covers operator 
training and programmer orientation. 


Documentation . GRASP is delivered in object 
code. Documentation, consisting of a system 
overview and user and programmer manuals, is 
produced by the user's computer through self¬ 
loading vendor-supplied tapes. For the most part 
the manuals are thorough and to the point. 


Maintenance . The package is fully guaranteed 
for the life of the installation. Enhancements are 
offered free of charge. 


HEADQUARTERS 

Software Design Inc. 
872 Hinckley Rd. 
Burlingame CA 94010 


HQ SAMTEC, AFL 2827 
TECHNICAL LIBRARY (PMET) 
VANDENBERG AFB, CA 93437 
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OVERVIEW 

GRASPVS is an automatic spooling system intended 
for the IBM System/370 running under DOS/VS. It 
resides in its own pageable partition in real storage, or 
may occupy a partition in the supervisor area (FO). Al¬ 
though primarily intended to spool I/O data, GRASPVS 
can optionally perform OS/H ASP-like job scheduling and 
dynamically changes job priorities as their processing 
characteristics change (I/O-bound to compute-bound, and 
vice-versa). It pools peripherals and dynamically allocates 
and deallocates them to any job in any partition (thus 
saving the number of peripherals needed in a mul¬ 
tiprogramming shop); it also employs warm restart and 
automatic volume recognition. GRASPVS handles local 
and remote batch jobs. 

The system requires a minimum of 4K bytes of real 
storage; a large system with remote terminal support 
requires between 8K and 12K bytes. About 20 cylinders 
of 2314 or 3330 disc must be allocated to spool data. 
GRASPVS is written in ASSEMBLER language. 

The system and its options are offered on a lease basis 
(see Table 1). There are approximately 2,000 users both in 
the U.S. and overseas. 

DESCRIPTION 

GRASPVS is a spooling program and group of service 
routines which compete with IBM's POWER, but offer 
many features not available with IBM's “bargain” spooler 
(e.g., OS/HASP-like job scheduling, peripheral device 
pooling, and automatic volume recognition, to name a 
few). 

Unlike POWER, GRASPVS operates asynchronously 
with problem programs and permits printing to occur con¬ 
currently with the processing. POWER, on the other 
hand, merely spools the data to tape or disc with printing 
occurring after the job terminates. The costs in hardware 
overhead discs or tapes are tied up and printers sit idle 
diminishes the on-the-surface savings one might believe 
he’s getting by using the less expensive POWER spooler. 

Basic GRASPVS offers the same spooling capability 
and the same basic facilities as GRASP. The new system, 
however, was designed from the ground up to operate in a 
virtual environment, while maintaining external compati¬ 
bility with GRASP. GRASP users will be able to convert 
to GRASPVS by merely cataloging the new spooler into 
their DOS/VS libraries. Strict compatibility was main¬ 
tained in the processing and layout of the following system 
components between GRASPVS and GRASP: account¬ 
ing file and record layout, load library modules, 
procedure libraries, spool files (including warm start). 
JCL, and operating procedures. For a description of the 
GRASP operating procedures, refer to Report Number 
607.6088.020 in this module. 


Principal features of GRASPVS are its Virtual Storage 
Operating Economies; Dispatching Monitor (optional); 
Dynamic Device Allocation (optional); Remote Terminal 
Support (optional); and Accounting and System Manage¬ 
ment Facilities (optional). These are described briefly in 
the following paragraphs. 

VS Operating Economies 

GRASPVS attempts to attain operating efficiencies in a 
VS environment (and that’s not easy, folks) by in¬ 
telligently managing buffer areas and by fixing only the 
more common routines in real storage. 

GRASPVS uses buffers to collect and disseminate unit 
record data. As a program creates print images, they are 
transferred into buffers. When the printer is ready to ac¬ 
cept the print images they are transferred out of the 
buffers. When in-memory buffers are exhausted, they are 
released after writing their contents to another storage 
media, usually discs. 

The management of the in-memory buffers plays a key 
role in the performance of the system. If not enough 
buffers are available, user tasks are impeded. If too many 
buffers are available, valuable memory is wasted. Com¬ 
pared to DOS, DOS/VS memory management facilities 
have been completely restructured. GRASPVS's buffer 
management routines are structured to optimize the use of 
real memory in a DOS/VS environment. 

Unlike spooling systems that allocate a fixed number of 
buffers for each unit record task, GRASPVS maintains a 
buffer pool and allocates buffers upon demand. When that 
task releases a buffer it is available to the task next in the 
buffer allocation queue. As tasks release buffers, they are 
given lowest priority in the buffer allocation queue. That 
prevents a task from locking out other tasks when its 
requirements for buffers dramatically increase. 

GRASPVS. generated for virtual residence, creates 
buffers beginning at the top end of a DOS/VS page. Page 
size in DOS/VS is defined as 2K of memory. Therefore, 
unless buffer size exceeds 2K bytes, a buffer will not cross 
a page boundary. Thus the DOS/VS overhead associated 
with Channel Command Word (CCW) translation is kept 
to an absolute minimum. 

GRASPVS does not fix buffers into memory but relies 
upon the DOS/VS memory management routines to 
provide buffer storage from the page pool. GRASPVS 
allocates free pool buffers residing in real storage before 
those residing in virtual storage. During periods when 
buffers are not required. DOS/VS removes them from real 
storage. When buffers are required, they are provided by 
DOS/VS. 

The buffer management therefore has a leveling effect 
upon memory allocation, and thus on the performance of 
user tasks. 
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The GRASPVS program itself preserves real storage by 
keeping only the code necessary to manage tasks fixed. 
This includes task status blocks and associated logic. Rou¬ 
tines which are not fixed include: remote terminal support 
logic, procedure library logic, reader spooling logic, com¬ 
mand processing routines, and buffers for local and 
remote devices. 

Dispatching Monitor 

The Dispatching Monitor solves the processing 
inequities of DOS/VS by more intelligently assigning 
processing priorities, and then monitoring these priorities 
to ensure optimum throughput. Under the IBM 
dispatching scheme, high priority jobs get processing pref¬ 
erence over their lower priority brothers. Thus a high pri¬ 
ority CPU-bound job could easily lock out an I/O-bound 
lower priority job, or a series of lower priority jobs which 
could make good use of the available resources. The net 
result is decreased overall throughput and/or poor re¬ 
source utilization. 

The GRASPVS Dispatching Monitor overcomes these 
inefficiencies by dynamically monitoring the dispatching 
sequence of the partitions under its control based on their 
use of resources. This monitoring is performed every three 
seconds, and priorities are changed or left unaltered 
depending on whether the jobs are I/O- or CPU-bound. 
CPU-bound jobs receive lower priorities. In cases where 
jobs are consistently compute- or I/O-bound, this altering 
of priorities amounts to a form of time slicing, something 
missing under both DOS and DOS/VS. If thrashing 
begins to occur, the Monitor automatically deactivates 
compute-bound jobs to allow I/O-bound programs to run 
concurrently. (We don’t agree with this procedure; see 
EVALUATION.) 

If several tasks are active within a partition, the CPU 
time used by the partition is computed as the CPU time 
used by all tasks. The relative priority of the partition’s 
subtasks is not changed, so that the standard DOS/VS 
rules for handling subtasks processing still apply. The pri¬ 
ority of the entire partition, though, is changed depending 
on whether it is I/O- or compute-bound. 

Dynamic Device Allocation 

The Dynamic Device Allocation (DDA) facility 
permits the pooling of discs, tapes, and unit record 
devices, and dynamically allocating them to requesting 
jobs regardless of which partition they’re running in. 
GRASPVS’s DDA offers three additional benefits: 

• Hardware need only be committed to a partition 
while actually required; this could reduce the total 
number of peripherals needed in a multiprogram¬ 
ming shop. 

• Device references are made to be symbolic rather 
than actual devices; thus JCL needn’t be juggled to 
run in various partitions. 

• Extensive operator intervention to handle con¬ 
flicting I/O assignments is eliminated. 


Table 1. Software Design GRASPVS: Features 
and Prices 

Charges $ 


Feature 

2 Yr 

Mo-to- 

Mo 

Basic GRASPVS 

370/1 15 

100 

120 

370/125 

100 

120 

370/135 

138 

165 

370/145 

192 

230 

370/155-11 

200 

240 

370/158 

200 

240 

Accounting Feature 

63 

75 

Automatic Volume Recognition 

21 

25 

Cataloged Procedures 

NC 

NC 

Channel Usage Accounting 

9 

11 

Compression (each) 

9 

11 

Console Reader Logic 

NC 

NC 

Core Resident Directories 

NC 

NC 

Deactivation Controller 

29 

35 

Dispatching Monitor (2 partitions) 

42 

50 

Dispatching Monitor (3 partitions) 

54 

65 

Dispatching Monitor (4 partitions) 

67 

80 

FO-VS 

54 

65 

Horizontal Tab 

9 

11 

I/O Devices Accounting 

7 

8 

Page Rate Monitoring 

NC 

NC 

Ports (each) 

104 

125 

Remote Terminal Support (Real) 

83 

100 

Remote Terminal Support (Virtual) 

129 

155 

Selective Tape Lister Interface 

NC 

NC 

Self-Relocatability 

83 

100 

Spooled Devices (each) 

33 

39 

Spooling Interface 

50 

60 

Symbolic Device Substitution 

14 

17 

System Units Accounting 

NC 

NC 

Tape Spooling 

18 

22 

UCS Translation Feature (each) 

5 

6 

Virtual Residence 

42 

50 

Virtual Transients 

33 

40 

Extended VS Activity Reporting 

28 

33 

Graspbil 

22 

26 

3211 Support 

33 

40 


A $100 installation fee is charged to install the system. 


The DDA works in conjunction with the GRASP au¬ 
tomatic volume recognition (AVR) facility, something 
also missing from both DOS and DOS/VS. With AVR, 
tapes and discs can be premounted and automatically 
found and assigned. 

Remote Terminal Support 

The Remote Terminal Support (RTS) facility spools 
I/O to and from local and remote devices. User programs 
are written as if the devices were local, therefore negating 
the need for programmers to learn communications lan¬ 
guages. 
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RTS works with EBCDIC and 6-bit transmission code 
and supports such terminals as the IBM Models 20, 2780, 
2770, 3780, 5985, and Data 100. Changes in terminal 
configurations or switching applications from local to 
remote is as easy as changing devices on a local system; no 
reprogramming of communications code is necessary. 
RTS support RJE and provides a system backup facility 
(in the event a line or terminal goes down) as well as a mul¬ 
tipoint line control. 

The RTS monitor requires an additional 8K bytes of 
real storage plus 2K bytes per device supported. It 
includes all line control, error recovery, etc., as well as 
spooling logic. There is no requirement for BTAM or any 
other supervisor communications support. 

Accounting and System Measurement 

Providing accurate, reliable accounting data, while 
keeping CPU overhead to a minimum, was the major 
design criteria used in the development of the GRASPVS 
accounting algorithm. Whereas other accounting systems 
perform their function each time the system changes state 
(each Supervisor call, each I/O event completion, each I/O 
event initiation, etc.), GRASPVS gathers its data upon a 
scheduled sampling interval. The length of the interval 
increases when the system is inactive. It ranges from 2 
milliseconds to 20 seconds. The GRASPVS accounting 
routines are entered 40 to 50 times less frequently than 
other accounting systems. Significantly more data can be 
captured by GRASPVS with considerably less overhead. 

Significant elements captured are: job name, phase 
name, computer operator, partition, time on, time off, 
elapsed time, non-MPS duration, interference duration, 
CPU duration (time spent executing instructions), opera¬ 
tor wait time, I/O wait time, phase loads, pages, lines, 
cards spooled, cancellation reason (if any), CPU model 
and serial number, GRASPVS assigned job number, start 
I/O counts. I/O device use time, SYSVIS, SYSRES use 
time, and CPU and channel activity. 

The non-MPS duration is unique to GRASPVS. It in¬ 
dicates the amount of time a job would have taken had it 
been the only job running. The non-MPS duration is the 
sum of the CPU duration, operator wait time, and I/O 
wait time. 

The Accounting module also contains several exits (or 
hooks) for user own code. Through these exits the user 
may capture installation-dependent data such as Depart¬ 
ment Number, Rerun Code, Project Number, etc., for 
inclusion in subsequent reports. 

Users may employ the accounting data to compute the 
cost of running a job via an optional billing program 
called GRASPBIL. GRASPBIL contains a costing al¬ 
gorithm which computes the bill based on built-in rates or 
rates established by the installation. An override feature 
bypasses built-in rates and allows each center to bill jobs 
in any manner desired. 


GRASPBIL prints a billing report and can be in¬ 
structed to punch cards containing billing data. Each ac¬ 
counting record printed may contain a summary line or 
optional detail lines. Each summary line contains the job 
name, step name (if any), GRASPVS assigned job 
number, partition identifier, date the job/step was run, 
time the job was begun, total computed cost for job/step, 
and user scratch area (if modified). 

Users may employ the accounting data to determine the 
efficiency and inefficiency of jobs in the mix. These sta¬ 
tistics are provided by four reports: Accounting Analysis, 
Exceptional Usage, Core Usage, and Resource Usage 
(CPU/Channel/Device). 

The Accounting Analysis statistics are produced in the 
form of system utilization reports. These reports are 
designed to assist both the data center manager and the 
systems programmer in the complex task of allocating 
costs, tuning, and monitoring the overall computer opera¬ 
tion. These reports can be of great assistance in: adjusting 
hardware configurations for maximum throughput; deter¬ 
mining which jobs are creating bottlenecks due to exces¬ 
sive usage of system resources; and analyzing the overall 
performance of the computer system and its components. 

The Exception Usage by System Resource report lists 
the 25 unique job names (or step names, if specified) 
having the highest usage of a selected resource. Up to four 
resources may be monitored for this exceptional usage, 
each producing an independent list of job or step names. 
Each list is ordered from the highest value at the top of the 
list. If a name should occur more than once, the number of 
occurrences (COUNT) will be maintained; however, only 
the highest value for that name will be displayed. Each list 
will contain only 25 names; therefore, a name once en¬ 
tered may be pushed from the list if its value is the lowest 
in the list. 

The Core Usage by Duration of Core Used report 
displays the core utilization based on the address of the 
last phase fetched/loaded relative to the beginning of the 
partition. An increment of 2K is used such that a job 
requiring 46.3K will be logged as requiring 48K. The 
number of jobs at each core increment is displayed along 
with the percentage of all jobs run. This indicates what 
percentage of the jobs run requires that core increment. 
The total job duration of jobs at each core increment is 
also displayed. The histogram following this job duration 
(TIME) indicates the percentage of all job durations at 
this increment versus the duration of all jobs. This addi¬ 
tional data can be of much assistance showing, for ex¬ 
ample, that although 10 percent of all jobs require 44K, 
this 10 percent accounts for 45 percent of the total job du¬ 
ration. 

The Resource Usage report accumulates data for the in¬ 
terval selected (daily or overall total), showing the time 
each resource was active. The time is used to compute the 
percentage that the resource was active. A bar chart is 
displayed to highlight excessive use. The percentage for 
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the CPU and Channel data is computed based on the dura¬ 
tion of those jobs containing such data, since it refers to 
overall system usage of resources. The percentage for 
device usage is based upon total job duration, as a given 
device may be used by many partitions during a given in¬ 
terval. 

EVALUATION 

GRASP is one of the most successful spooling packages 
on the market, and it’s not hard to figure out why. Its 
asynchronous processing-printing capabilities, coupled 
with features like multiple print file spooling (POWER 
cannot handle two printers in one partition), warm restart, 
partition load balancing, and pseudo-device spooling, 
make GRASP an attractive alternative to POWER. (The 
pseudo-device feature is only a disc extent with its own 
address; it does however save the cost of reader, punches, 
and printers by spooling second and third partitions.) 

GRASPVS carries over these same features, and adds 
the new capabilities described in this report. The net result 
is a powerful system with proven capabilities plus some 
slick new features — all of which function in a virtual en¬ 
vironment. 

One of the more impressive features is the Dispatching 
Monitor. Its dynamic sensing of job processing character¬ 
istics and the alternating of priorities is most impressive. 
We must, however, question the criteria used to handle 
processing when thrashing begins. Under the current 
procedure, compute-bound jobs are rolled out to allow 
I/O-bound jobs to run concurrently. Granted, this is the 
ideal situation provided the jobs are not competing for the 
same device or channel used for paging. Such competition 
causes bottlenecks which in turn results in processing deg¬ 
radation. 

By merely kicking out the compute-bound job with no 
consideration for whether it is excessively paging or com¬ 
peting for device servicing will not necessarily improve 
throughput. It could, in fact, have the opposite effect. A 
better criteria, we feel, would be to determine those jobs 
creating the bottlenecks and then either roll-out the 
highest pagers, or the least critical. 

We interviewed a number of GRASPVS users to gain 
their reaction to the system. All had the system for less 
than two months, and none had converted from GRASP. 
Most were using the basic spooling package, and none had 
the Dispatching Monitor. 


The comments were generally quite favorable. All felt 
the system increased throughput and was well worth the 
money. One had converted from POWER, and another 
had converted from a competitive independently vended 
system. 

There were a few minor complaints voiced. For ex¬ 
ample, one user was running the basic system on a 
370/145 with 3340 discs being used for GRASPVS resi¬ 
dence and spooling. He indicated that he could not 
catalog the control program beyond cylinder 255, and 
thus had to move his other libraries. He appraised the 
vendor of the problem and was expecting a patch shortly. 
This really is more of a nuisance than a problem; but we 
are mentioning it in case the fix is not generally released. 

This same user indicated that when driving two printers 
(one per partition) and a card reader that GRASPVS filled 
the buffers too fast for the printers to handle. The 
overflow data also quickly exceeded the 20 cylinders 
reserved for this purpose, with the result that the partition 
became tied up. He remedied this by devoting a complete 
3340 for spooling, but conceded that the entire pack was 
by no means being fully utilized. 

Now it could be that this user was running fairly long 
reports (he didn’t have line counts available) and would 
have been better off spooling to tape. However, it’s some¬ 
thing to consider in case you’re thinking of spooling long 
reports and are planning to devote a minimum area for 
spooling. 

In conclusion, we feel that GRASPVS is one of the 
more sophisticated packages of its type available, and is an 
excellent alternative to POWER. The drawbacks men¬ 
tioned are not all that serious, and could be overcome with 
some sensible planning on the part of the user. 

SUPPORT 

The system is fully guaranteed against source bugs for 
the life of the installation. New releases are free, and no 
charge is levied for normal maintenance. 

SDI does charge $100 to install each system; if the user 
converts to a new version of GRASPVS after 90 days of 
the initial installation, a $50 service fee is charged. 

HEADQUARTERS 

Software Design, Inc. Software Design, Ltd. 

2460 Lemoine Ave. 24A Chemin Ed-Sarasin 

Fort Lee NJ 07024 121 8 Grand Saconnex 

Geneva, Switzerland 
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OVERVIEW 

VM/370 ISAM is a simulated indexed sequential access 
method under CMS for VM/370; it is an alternative to OS 
ISAM. It runs on an implementation of CMS, requiring 
320K core and no specific peripherals for its use. Written 
in BAL, it is available for immediate installation. 

The permanent license costs $10,000; the 36-month 
lease/license costs $327/month; and the monthly rental is 
$250. 

The package was introduced in May 1973 and is cur¬ 
rently used in 15 installations. 

DESCRIPTION 

Unlike an OS ISAM file, a CMS ISAM file actually 
consists of two distinct files — the data file and the index 
file. The data file contains sequenced data records which 
can be accessed from disc in fixed size blocks for conven¬ 
ient searching. The index file provides a convenient 
method of locating the data block containing the data item 
in question. 

Each logical record in the data file must include a 
collating key which is used for locating the record in the 
file. The key is extracted from the record and stored in 
front of it to facilitate scanning when searching for a par¬ 
ticular record. Scanning the file is accomplished by look¬ 
ing only*at the keys. Following each key is a pointer to the 
key location of the next logical record. The key, link, and 
data records which comprise an original ISAM file are 
contained in the primary section of the file. Each ISAM 
file also contains an overflow section in which are placed 
the key, link, and data records for later additions to the 
file. 

The index file consists of a hierarchy of one or more in¬ 
dexes analogous to the track, cylinder, and master indexes 
used with OS. 

The VM/370 ISAM system can be invoked via 
COBOL, PL/I, or Assembly language. It supports the OS 
Assembly language macroinstructions and their COBOL 
and PL/I equivalents. 

VM/370 ISAM also provides a CMS ISAM utility com¬ 
mand to create, dump, and reorganize an ISAM file. This 
command eliminates the need to write a PL/I, COBOL, or 
Assembly language program to accomplish the identical 
function. 

PROCESSING 

Input 

To create an ISAM file, the data in sequential order and 
the name of the ISAM file to be created must be provided. 
For other operations on the file, generally only the file 
name must be entered. 


Process 

The ISAM records are stored on disc in fixed size data 
blocks. There is no indexing within a data block. To locate 
a record the system searches through the set of keys in the 
data block by following the pointers. The index is used 
only to locate the data block which should be accessed so 
that the time-consuming sequential search within the data 
block is limited to the number of records within the 
data block. 

As the ISAM file is being created, whenever a data 
block is filled an entry is made in the index. The entry con¬ 
tains the highest key in the data block and a pointer to the 
first data item in the block. If the number of index entries 
exceeds a limiting value, it becomes impractical to store 
all the index entries in core. The index entries must then 
be stored on disc and a higher level index must be created. 
Each grouping of lower level index items is called an 
index block. When each index block reaches the limiting 
size, an entry is made in the higher level index with a 
pointer to the highest key in the index block. The higher 
index remains in core and is called a master index. 

If the number of entries in the master index exceeds the 
limiting value for storage in core, a third index level is 
created. The process of creating additional index levels 
continues until the number of items in the master index is 
small enough to remain in core. 

Once the file is created, file manipulation can occur 
through the use of simple commands. These commands 
allow file clearing, dumping, reorganization, and 
displaying file contents. 

Output 

Besides the ISAM file, VM/370 ISAM provides such 
information as the number of index levels and the number 
of overflow records. 

EVALUATION 

COBOL, PL/I, and Assembler programs which run 
under OS can use VM/370 ISAM without changes to their 
source code. However, several restrictions exist; 

• The “resume load” mode of the PUT macroinstruc¬ 
tion, i.e., add records to the end of the data set, is not 
supported. 

• The R option of the OPTCD DCB parameter is not 
supported. 

• The RELSE macro in QISAM input mode is not 
supported. 

• Actual device addresses are not supported; 
therefore, the I and ID options of the SETL macro 
and the DSORG-ISU parameter of the DCB 
macroinstruction may not be specified. 

• ISAM files cannot be created using a PL/I program. 
The ISAM LOAD utility can be used in its place. 
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• A PL/I program cannot issue a sequential WRITE 
to an existing ISAM file. All ISAM files must be up¬ 
dated using DIRECT or RANDOM mode. An 
ISAM file can be read sequentially. 

Most of these restrictions are insignificant since there 
are programming techniques which can get around the 
restriction. More important is the fact that this package 
provides an ISAM capability for the CMS environment, 
a feature not available from IBM. For this reason, 
package users are delighted with the capability and con¬ 
sistently laud Standard Data’s product line and service. 

SUPPORT 

Vendor representatives are on site for one day to install 
the package and instruct user personnel in its use. They 
provide a user manual (which, while not excellent, 
provides enough information to get by, according to one 
user). There is no charge for maintenance for a leased 
package; a nominal yearly fee is levied for maintenance of 
purchased systems. 

HEADQUARTERS 

Standard Data Corporation 

1 540 Broadway 

New York, NY 10036 
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OVERVIEW 

VSORT, the Integrated CMS Sort System, is an OS 
sort compatibility for CMS. It runs on a System/360 or 
370 under CMS. Written in BAL, VSORT requires at 
least 20K bytes of storage; it dynamically allocates more 
storage if it is available. When the input data is an 
unblocked disc file and all sort keys can be held in core, 
then no intermediate storage is required. When this situ¬ 
ation does not exist, VSORT requires disc work files the 
same size as the input files. 

The package is available for immediate delivery and 
costs $10,000 for a permanent license, $327/month for a 
36-month lease/license, or $275/month for a monthly 
rental. 

Introduced about a year ago, VSORT is operational in 
five installations. 

DESCRIPTION 

VSORT handles a wide variety of sorting applications. 
It functions as a stand-alone utility, as support for the 
COBOL SORT verb, or as a subroutine callable from 
PL/I or Assembly language routines. It can be used as 
part of a CMS application or an OS application being de¬ 
veloped under CMS. All of the OS control field defini¬ 
tions, formats, and restrictions are supported. VSORT, 
which replaces the IBM CMS stand-alone sort, may be 
used with disc or nondisc resident files. 

The package sorts blocked or unblocked sequential 
files containing fixed or variable length records with a 
maximum record size of 32K. 

User written routines can supply input records or re¬ 
ceive the output records when the sort is invoked by a 
COBOL, PL/I, or Assembly language routine. For con¬ 
versational use of ICS, a simplified command format is 
available. 

The vendor claims VSORT runs from two to 12 times 
faster than the IBM CMS stand-alone sort distributed 
with the CMS system, although the actual run time is de¬ 
pendent on the size of core, number of records, and the 
sort key. 

PROCESSING 

Input 

Besides definition of the input, output, and message 
data files, the user must describe the sort operation to 
take place. This information is provided in a few state¬ 
ments which describe the control fields and file size, 
record length, and type of data to be sorted. 


Process 

Each record in the file is sorted on the basis of up to 
64 control fields. Each field may be up to 256 bytes long 
and may overlap other control fields. 

Based on these control fields, records are sorted in ei¬ 
ther ascending or descending order, using standard IBM 
System/360 collating sequences. Character and binary 
fields are not interpreted as having signs. Each packed 
decimal, zoned decimal, fixed point, and normalized 
floating-point field is interpreted as having an algebraic 
sign. 

When a field to be sorted does not meet VSORT 
requirements, it aborts with an explanatory message. 

Output 

In addition to the sorted file, VSORT supplies a count 
of the number of records sorted and periodic messages as 
phases of the sort are completed. 

EVALUATION 

Standard Data’s VSORT package is far and away a su¬ 
perior sort package to IBM’s sort. Unlike the IBM 
package, VSORT can sort data in ascending and de¬ 
scending order (IBM’s can handle only ascending). 
VSORT can be called from a higher level language, 
while the IBM sort cannot. And VSORT operates two to 
12 times faster than IBM’s sort operation. 


Interviews with package users confirmed all claims 
which the vendor makes about VSORT. It is faster and 
more versatile than its competition, and support is 
always on hand when needed. 

SUPPORT 

Vendor representatives are on site for one day to in¬ 
stall the package and instruct user personnel in its use. 
They provide a user manual as documentation. There is 
no charge for maintaining a leased package; a nominal 
yearly fee is levied for maintenance of a purchased 
system. 

HEADQUARTERS 

Standard DataCorp. 

1540 Broadway 
New York NY 10036 
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SUBSYSTEMS INC. 
Easy Reader 


OVERVIEW 

Easy reader is a proprietary system program that 
significantly augments the facilities of OS/360 Job 
Management’s reader/interpreter routine. Easy Reader 
allows the user to construct his own JCL procedure library 
in any partitioned data set (PDS), execute the cataloged 
procedures out of that PDS or SYS1 .PROCLIB, and 
maintain the user procedure library. Additionally, the 
package eliminates JCL ABENDS due to nonexistent or 
unusable procedure libraries. 

The package is available for all OS versions: VS1, VS2, 
VM, HASP, and ASP. OS versions are priced at $1,000 for 
a permanent license plus $25 per month for maintenance; 
VS versions are $2,000 for a permanent license, and $50 
per month for maintenance. 

Description 

Easy Reader consists of a set of modules which are link- 
edited into the standard reader/interpreter without 
modification to the IBM code. Installation of the package 
requires a maximum of one hour of programmer time plus 
approximately fifteen minutes of processor time. 

The program’s operation is totally transparent to the 
user, since it operates in place of the IBM-supplied 
reader/interpreter. When activated, the routine will ref¬ 
erence either the system procedure library (SYS1.- 
PROCLIB), or will concatenate a user-defined procedure 
library to SYS1.PROCLIB if a PROCLIB DD card is in 
the input JCL. The package permits an unlimited number 
of user procedure libraries in the system, and allows any 
job to use up to fifteen separate PROCLIBS in a given run. 
Easy Reader has the distinct advantage of not ABENDing 
any job because of either nonexistent or unusable 
procedure libraries. 

PROCESSING 

Subsystems, Inc. provides the user with a tape 
containing three files; complete documentation for 
installation and use, including a complete JCL description; 
and comprehensive error message documentation. 

The tape provided supplies the user with: 

• Complete user documentation in upper/lower case. 

• Two jobs used to install Easy Reader. The first job 
consists of two link-edit steps and an IEBCOPY step 
that incorporate reader/interpreter aliases, add re¬ 
quired Easy Reader aliases, and copy the Easy Reader 
CSECTS and aliases into SYS1 .LINKLIB. The second 
job renames the present IEFVHA with an initial ‘O’, 
renames the Easy Reader entry points with an initial 
‘I’, and thereby establishes the package as the system 
reader/interpreter. 


• Three jobs titled DEINST1, DEINST2, and DEINST3 
used respectively to: temporarily turn-off Easy Reader 
by renaming the saved IBM reader/interpreter and 
Easy Reader; completely remove Easy Reader by 
scratching the Easy Reader CSECTs and renaming the 
saved reader/interpreter; and remove Easy Reader and 
to rebuild the original reader/interpreter. 

During operation, Easy Reader provides all normal 
reader/interpreter functions such as interfaces to the com¬ 
mand scheduling routine and the input work queue, plus 
the all-important added function of concatenating user- 
defined proclibs to the SYS1 .PROCLIB. 

OUTPUTS 

The primary outputs from Easy Reader are error 
messages that provide the user with comprehensive data as 
to the reason or reasons why a JCL error was noted. Error 
message categories include a set of invalid keyword error 
messages for VOL = , REF = , SER = , DISP = , and 
DSN =, system interface, mount, DSCB, and user 
PROCLIB data set error messages. Following issuance of 
an error message, processing continues with the next job in 
the input queue. 

EVALUATION 

At present, Easy Reader has approximately 100 users; 
among them are some of the largest installations in the 
U.S. Although only a relatively small sample of these 
many users was contacted for this report, the responses 
were uniformly favorable. This was not surprising to us, 
considering what the package does, its relatively low cost, 
and the comfort of knowing that the next ABEND would 
be because of some obscure, possibly esoteric system short¬ 
coming — not because of a common JCL booboo. The 
package works as advertised, has undergone numerous 
benchmark tests, and has had thousands of hours of run 
time in its one year’s existence. 

For the installation that has very large SYS1.- 
PROCLIBs, the overall cost of those effectively idle spin¬ 
dles can be considerable. Easy Reader provides an inex¬ 
pensive solution. For those installations that would like to 


HEADQUARTERS 

Subsystems, Inc 
790 Lucerne Drive 
Sunnyvale CA 94806 
(408) 733-0190 
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have a very large SYS1 .PROCLIB, Easy Reader is also the 
answer. And for those RJE users who have calculated the 
costs for transmitting JCL, Easy Reader could possibly in¬ 
crease their available line, while simultaneously reducing 
their costs per job. 


SUPPORT 

The vendor provides full on-going support for all ver¬ 
sions and releases of Easy Reader. An example of such 
support would be if the user goes from a non-virtual to a 
virtual system or vice versa. 
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OVERVIEW 

Deadline II, a computer center scheduling system, 
presents schedules of both manpower and machines for 
daily tasks. It includes data entry, library activity, CPU, 
and peripheral devices. Schedules may also be forecast in¬ 
definitely into the future for resource planning purposes. 

The system runs on the IBM System/360 Model 50 or 
HIS 635 with a minimum of 150K bytes of main core 
storage, two magnetic tape drives, and 23 14 or 3330 disc. 
It is written in ANSI Cobol. 

It may be purchased for $24,500 under a license 
agreement or leased for $950 a month with a $2,000 in¬ 
stallation fee. Introduced in early 1972 under the name of 
Deadline, there are now a total of 29 installations, 10 of 
which are the original version. 

DESCRIPTION 

Deadline II is intended to aid in the planning and 
scheduling of data processing department tasks by analyz¬ 
ing manpower and equipment available. 

As a planning tool, the system allows evaluation of al¬ 
ternative equipment use and staffing levels and helps the 
planner to decide the proper mix to accomplish all tasks 
most efficiently. The types of analysis in the planning 
mode are: percentage utilization of equipment; the impact 
of increased workloads; and the evaluation of manpower 
needs, shift, and overtime considerations. By proper anal¬ 
ysis of the reports, system imbalances and bottlenecks that 
occur in operations throughout the computer center can 
be identified. 

In scheduling. Deadline II handles processing from 
source data input to final output and disposition. All work 
to be scheduled is structured into jobs and tasks within 
jobs. Tasks are then allocated through the required activi¬ 
ty areas, such as keypunch, computer, and report control; 
and schedules are produced for individual resources or 
groups of similar resources depending upon management 
needs. 

Deadline 11 attempts to schedule each task by first using 
the primary resources available. If desired completion 
dates cannot be met, alternative methods involving over¬ 
time, extra shifts, or external processing are set up. In¬ 
terjob dependencies set by the user are taken into consid¬ 
eration as schedules are established. Job priorities may be 
reordered to maintain overall schedule objectives. Tasks 
are time-phased to accommodate delays caused by physi¬ 
cal transfer of work between work areas. 

Deadline II also handles rescheduling of jobs when 
unexpected changes occur. Only exceptions in perform¬ 
ance against the previous schedule need be specified and a 
separate production file for regularly scheduled jobs is 
maintained. 


Deadline II produces three main reports: a job sched¬ 
ule, which reports the adequacy of specified resources in 
meeting established deadlines; a report of unassigned 
resources, which assists in assigning on-demand work 
resources; and a shift activity schedule which shows 
chronologically the work to be performed in each 
resource area (work center) by shift. 

Some significant system features of Deadline II are: 

• Schedules can be constructed for a one through 35- 
day period and forecasts can be made up to the 
length of the calendar defined by the user. 

• Up to four subsources of a computer configuration 
can be handled. 

• Task scheduling can be made in increments of five 
minutes and can be reduced to the OS job step level. 

• Up to 99 work centers can be considered, each with 
99 resources (men or machines). 

• A calendar extraction routine is offered to provide 
automatic extraction from the workload master file 
by calendar day. 

• Task throughput is 2,750 per hour. 

• There is a report showing interdependency and par¬ 
allel crossreferencing of jobs. 

• Operator instruction can be channeled to each 
resource area by time or shift. 

PROCESSING 

Input 

Input consists of card groups and two master files. The 
first file, called the resource master file, essentially con¬ 
tains data concerning the equipment and staff available 
plus their capabilities. The second master file, called the 
workload job/task master, contains all recurring jobs and 
tasks. Both files can be updated during a run. 

The card groups detail the jobs to be done, resource 
requirement (man/machine hours), job priority number, 
files to be updated, reports to be generated, number of 
days to be scheduled, and acceptable days of slippage. 
This data interacts with the two master files and by simu¬ 
lation techniques produces the schedules and reports. 

Key cards in this group deal with task description 
where data is specified for each task performed within a 
job. Included are job number, task number, and task 
description data. 

Also contained on these cards are the resource assign¬ 
ment level and resource requirement fields. The resource 
assignment level contains subfields for feasible minimum, 
normal, and maximum performance levels. Only one of 
these fields may apply or need be used. Primary resource 
fields specify information related to the preferred 
resources to be used in completing a task. 

At the user’s option, a resource number may represent a 
single person or machine, or a group of either. For com¬ 
puters, individual machines are ordinarily designated. An 
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option is available to specify a maximum of three primary 
resources under subfields A, B, and C. Each primary 
resource specified is assumed to have the same resource 
requirement and concurrent task code. 

The concurrent task code field designates that the task 
can be performed simultaneously with other tasks and is 
usually used for computer processing. The code itself 
reflects the maximum number of initiators that the user 
wants active during processing. When this field is not 
completed, the computer is assumed to operate in a 
sequential batch basis. 

If the start of a job is contingent on another being 
finished or if two or more tasks within the same job can be 
processed in parallel, the user must note this interdepen¬ 
dency. The system can schedule parallel processing only if 
the task resources are available in sufficient quantity. 

Process 

The system employs simulation techniques to form op¬ 
timum configurations to meet tasks and priorities. 
Deadline 11 has two general priorities: specified and com¬ 
puted. Specified priorities are set by the planner using pri¬ 
ority numbers entered on job cards. These priorities are 
for jobs requiring the earliest possible completion or the 
maximum guarantee of being finished on schedule. Two 
specified priority groups are allocated in order to provide 
the option of interrupting ongoing tasks that were desig¬ 
nated interruptable. 

Computed priorities are automatically generated by the 
scheduling system. These depend upon additional factors, 
such as scheduled job completion time or slippage in the 
start of jobs. Specified priorities always override com¬ 
puted ones. 

After all job priorities have been established, a schedule 
is produced by taking jobs in descending order, selecting 
available resources, and establishing time required 
including delays for transfer of work between areas. In¬ 
terjob and task dependencies are figured in computing the 
time necessary to complete jobs. 

When a desired completion time is specified for a job, 
Deadline II first attempts to meet it at a normal resource 
assignment level using the primary nonpremium 
resources specified. If completion cannot be achieved by 
the desired time, the system will attempt the use of 
increased resource assignment level, up to the maximum 
level specified. The system makes further attempts to ac¬ 
complish the job using alternate resources at a second and 
third level if completion cannot be accomplished. Only 
when all resources and specified alternatives are 
exhausted will Deadline II indicate a job overrun. 

In the case where concurrent processing is feasible for 
both the task and the resource. Deadline II attempts to 
schedule tasks concurrently. When concurrent scheduling 
occurs, the maximum number of programs the computer 


can process and the availability of required subresources 
(tapes, disc, printers, etc.) are not allowed to be exceeded. 

Output 

The system produces three major reports: the job sched¬ 
ule, the shift activity schedule, and the resource utilization 
report. 

The job schedule shows the adequacy of specified 
resources to meet established deadlines. If schedule slip¬ 
page occurs, this is noted on the report, showing late time 
in hours and minutes. Work is traced through each activi¬ 
ty — from keypunch to final report disposition — with 
any delays noted. In addition, the report gives time to 
complete the job in hours and minutes, clock time in and 
out, and resource code which may be used as a cross refer¬ 
ence to the shift activity report. 

The shift activity schedule is formatted by work center, 
resource, and shift for the scheduled period. Tasks are 
listed in the order of occurrence for the particular 
resource (human or machine) and a page is reserved for 
each shift. 

The resource utilization report shows both the initial 
availability of each resource and those resources or parts 
of resources unused by scheduled activities. This report 
pinpoints by day and hour those resources available for 
special unscheduled activities. 

In addition to these reports, a forecasting module can 
optionally prepare a histogram showing the percent 
utilization of all resources by shift. This report is broken 
down by each resource and reflects the calendar as defined 
by the user. 

Finally, Deadline II provides a source data listing and 
an error report. Data cards are listed, preceded by appro¬ 
priate error codes. 

EVALUATION 

The key problem facing most operation centers is effec¬ 
tive resource scheduling to satisfy the needs of the job 
mix. I n our opinion, Deadline 11 only partially automates 
this scheduling. 

To obtain optimal scheduling, many installations rely 
on the usage statistics provided by the system resource 
monitoring facility. (Under IBM's OS, this is provided by 
SM F.) I n a fully automated system, the usage statistics are 
further refined and used in assigning resources to jobs and 
tasks. 

Although Deadline II has a facility for obtaining SMF 
data, employing it to schedule resources has proven to be a 
difficult task. The problem lies in correlating SMF codes 
to Deadline II job/task codes. Standards are not provided 
and they might be difficult to develop unless some auto¬ 
matic feedback system is established from the SMF and 
from other work centers as well. 
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Another “soft” area of Deadline II is its standard 
reports. Although the information is quite complete, inex¬ 
perienced users have found it difficult to read since it 
requires the translation of codes used for resources, 
job/tasks, etc. 

On the operational side. Deadline II has proven to be a 
valuable tool to many users. One installation, after run¬ 
ning Deadline II for a year and a half, is now meeting 98 
percent of its schedules. 

SUPPORT 

Support received from Tesdata was characterized as 
“very good” by the users with whom we talked. They also 
noted that developing the data base was an extremely 
worthwhile although difficult task. 

Tesdata charges travel expense plus per diem to install 
the package and train personnel. Users receive documen¬ 


tation and five days on-site consulting time. This is usually 
taken with three days initially and another two days after 
two months. Any time required beyond that is billed on a 
fee plus out-of-pocket expense basis. 

Installation includes training in system concepts and 
operation, any desired minor modifications, and several 
copies of a 300-page user manual. 

The system is guaranteed against source code bugs for a 
set period of time. Routine maintenance support by mail 
or phone is furnished on a continuing basis during normal 
business hours. 

HEADQUARTERS 

Tesdata Systems Corporation 

7900 Westpark Drive 

McLean VA 22101 
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OVERVIEW 

Streamline is an automated scheduling system that 
provides guides on how to optimally schedule jobs and 
tasks while maximizing system resource utilization. It 
works in a multiprogramming and multiprocessing envi¬ 
ronment, can be interfaced with SMF data, and produces 
a series of predictive reports which may be used to adjust 
schedules to avoid conflicts. 

Streamline operates on an IBM System/360 or 370 
under OS and OS/VS and requires approximately 100K 
bytes of main memory and about half of an IBM 23 16 disc 
pack. Source language is PL/1. Purchase price is $20,000. 


DESCRIPTION 

One of the biggest headaches facing the data processing 
manager is the effective scheduling of jobs to meet 
deadlines, while avoiding resource conflicts and/or unnec¬ 
essarily tying up resources. Another pain is the re¬ 
scheduling of jobs and resources to meet the usual 
“shotgun” situations common in many installations. To 
these problems, Streamline offers an aspirin in the form of 
excellent scheduling and resource utilization information. 

The principal function of Streamline is to provide 
management-level information which can be used to plan, 
schedule, and control production processes in a data proc¬ 
essing center. As a planning tool, it provides a series of 
predictive reports showing future demands, and offers 
predictive schedules showing the job mix and workflow 
needed to obtain optimum performance. Suggested pe¬ 
ripheral pool allocations, initiator/partition assignments, 
job classification and job scheduling priorities are given 
— all designed to eliminate contention for key resources. 

As a scheduling tool. Streamline provides multilevel 
management reports showing work to be scheduled, 
broken down into jobs and tasks within jobs. The jobs 
provide most of the scheduling parameters; the tasks 
complete this data and add the performance data used for 
multiprogramming scheduling. Schedules are also 
produced for individual processors, groups of processors, 
or external users. 

To improve performance, Streamline provides for the 
scheduling of tasks and leveling of workflow across all 
processors. The system maintains a resource map and con¬ 
siders task performance data and resource requirements 
prior to scheduling. Thus jobs that can run on several 
processors can be scheduled on the one most suited (at 
that time) to run it. Operator performance is also 
enhanced by information outlining shift load, standby 
resources (for nonscheduled emergency jobs), and the ini¬ 
tiator configuration. 


PROCESSING 

Input 

Streamline inputs are comprised of three system 
libraries, plus source data. The latter may be entered via 
user-supplied cards, or SMF data may be input directly. 
The first library, called the Master Resource Library, lists 
all processors and their related peripheral devices. The I/O 
devices are described by their connectivity, use, status, 
and unit type. 

The second library, the Master Job/Task Library, iden¬ 
tifies and describes jobs and tasks. A job is the largest 
schedulable entity and as such, the job descriptions 
include specification of its scheduling attributes. A series 
of tasks comprising each job determine the performance 
characteristics of the job. The correlation of the job and 
task data is performed automatically by Streamline. Capa¬ 
bilities for modification, deletion, and addition to the 
library exist in both the utility and scheduler components 
of Streamline. The techniques employed allow the user to 
add or delete total job and tasks or to modify selected 
fields in the library records. 

Skeletal job records and complete task records can be 
produced through automatic data collection utility. The 
records can be entered directly into the library or produc¬ 
tion tested to assure accuracy. After initial schedule integ¬ 
rity has been established, the Master Library can be up¬ 
dated using these records. 

The final library, the Master Data Set Library, contains 
a correlated collection of the installation’s tape and disc 
data set inventory. This essentially eliminates tape/disc 
proliferation caused by inadequate control and provides 
improved schedules since the system uses the resource 
listing when scheduling. 

The source data is supplied by the user or, where 
applicable, by SMF and is used by Streamline to control 
its facilities. The source data falls into four basic groups: 
schedule control; job and task information; resource in¬ 
formation; and availability exception information. 

The schedule control data supplies Streamline with the 
information needed to establish basic scheduling 
parameters. This data indicates the start and end times of 
the schedule. Minimum scheduling interval varies from 
one to 21 minutes and the maximum schedule duration is 
one to 21 days. Also entered, usually by card, is 
rescheduling information and output control information. 
The rescheduling capability allows the user to include 
previously scheduled jobs on one or more processors in 
the new schedule. 

The job and task data specifies overall data pertaining 
to each job. If entered manually, two separate cards are in¬ 
volved. The job card furnishes the job name, job descrip¬ 
tion, start time and desired completion time, job priority, 
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number of tasks, and delay times. The latter allow the user 
to provide an additional time dimension to job inter¬ 
dependency and can be used by Streamline to resolve job 
interdependencies. A time period from one minute to 24 
hours can be requested for each job in the chain. Also on 
this card the user may specify specific processors, 
operating system, and partitions for a job. 

The task card is used to specify data for each task to be 
performed. (It could be created with the automatic data 
collection feature of Streamline.) The task card allows the 
planner to specify performance characteristics for each 
task, and adjust the running time to reflect actual perform¬ 
ance. For example, elapsed, CPU, and intervention times 
may be specified. Elapsed time is specified when I/O activ¬ 
ity cannot be adequately entered. The CPU time field is 
entered as the actual value or in conjunction with elapsed 
time to indicate the CPU to I/O ratio. The intervention 
time parameter is used to adjust running time to reflect ac¬ 
tual operational performance. This field encompasses 
time delays for tape, disc mounting operator interaction, 
special forms mounting, etc. A center operating close to 
schedule can analyze these task fields to isolate tasks with 
high levels of manual interaction. 

The resource description card describes each processor 
and I/O device scheduled by the system. Processor iden¬ 
tification, System, and model constitute the primary infor¬ 
mation. One processor is designated by the user to be the 
base, while all others are calculated as having a speed rela¬ 
tive to that of the base processor. Depending upon the 
operating system chosen, this card may also contain infor¬ 
mation concerning dynamic storage availability and 
default storage requirements for the problem programs. 

The I/O device description contains processor iden¬ 
tification, hardware address, and unit type to which the 
I/O device is attached. The user may also designate which 
I/O devices may be shared among processors; up to three 
additional processors may access a particular device. 

The availability exception cards indicate changes in the 
hardware and operating systems available during the 
scheduling period. These dynamic variations are consid¬ 
ered temporary for the period indicated. 

Process 

Processing is carried out in three distinct phases: 
scheduling, management facility, and utility facility. 
Scheduler phase interfaces to the system workload and 
resource information input to produce the various sched¬ 
ules and management reports. The management facility 
provides an interface to the installation statistical collec¬ 
tion routines for presentation of actual processing results 
and workload update records. The utilities interface with 
the system input to maintain the installation libraries and 
produce management and inventory reports. 

In scheduling, the system employs simulation and per¬ 
formance optimization techniques to provide scenarios of 


worktlow and resource utilization for the ensuing 
scheduling periods. 

Based on the information contained in the schedule 
control and resource availability records, the scheduler 
initializes the various control tables and establishes the 
centers resource matrix. The connectivity, availability, 
and status of all I/O devices is determined and the periph¬ 
eral pool is established. If no change in availability is in¬ 
dicated, Streamline constructs the resource network from 
the information in the master resource data set. 

When rescheduling, jobs and tasks are automatically re¬ 
trieved from the previous schedule. The system input 
stream indicates the additional workload requirements by 
job name for each schedule, and provides updates to pre¬ 
stored information and exceptions from the previous 
schedule. The performance data for all jobs in the sched¬ 
ule is automatically retrieved from the library and the task 
run times are calculated. 

Processing of each task is determined by resource 
requirements, priority, earliest start time, desired comple¬ 
tion time, and job interdependencies. The Streamline al¬ 
gorithms calculate the critical path through the workload 
with this data. The jobs with their dependencies resolved, 
internal priorities computed, and run requirements es¬ 
tablished are presented to the next phase for scheduling. 

The job descriptions are processed by the scheduling al¬ 
gorithm in internal priority order. The system considers 
each job based on its schedule time bounds, and selects the 
best processor for running the job. The change in 
resources is calculated and the resource matrix and pe¬ 
ripheral pool updated to reflect the demands. If sufficient 
resources are available for processing the job, the system 
schedules the job at the earliest possible time. Run times in 
a multiprogramming environment are calculated. The ini¬ 
tiator designation and dispatching priority to effect the 
schedule is made by the system. Streamline is then 
prepared to respond to any reporting requirements called 
for by the system control card. 

The SMF capability also can be used to automatically 
update the data base. ABENDS are mated by SMF as they 
occur, and corrective action can be taken. 

The management facilities provide feedback on the ac¬ 
tual performance of the scheduled workload. In doing so, 
the system extracts selected performance data on jobs and 
tasks from installation master file. After sorting the per¬ 
formance data in chronological order, the system provides 
actual chronological processor reports and job/task up¬ 
dates. Job reruns and abnormal terminations are iden¬ 
tified in order to focus management attention on a major 
source of missed deadlines and schedule deviations. 

The utility facilities consist of a series of programs 
which maintain the system libraries. Both a create and an 
update mode are provided. 
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Output 

Streamline is capable of producing a myriad of infor¬ 
mation, covering: 

• Management Reports — center job flow schedule; 
department area report. 

• Operational Reports — chronological processor 
schedule; peripheral pool report; processor graphic 
scenario. 

• Inventory Reports — job/task report; hardware 
resource report; data set report. 

• Utilization Reports — chronological process report; 
abnormal termination report; discrepancy report. 

The center job flow shows the job name, tasks, earliest 
start time, desired completion time, initiator/partition 
designator, processor, dispatching priority, core 
required, inter-job dependencies, and job runovers. 

The chronological processor schedule details the activ¬ 
ities on any processor. This report allows the user to 
judge the performance of each job or task on a given 
processor. 

Another management report shows what was ac¬ 
complished versus what should have been accomplished 
— with variances in schedules and run times. 

The graphic scenario report details the number and 
logical designations of initiators/partitions. Shown are 
task start and end times, the maximum number of mul¬ 
tiprogramming levels per initiator/partition, and the 
available resources. 

The job/task report is a review of the totality of the 
stored file information on the center’s jobs and tasks. 
This information consists of performance data gathered 
by Streamline and augmented by the center’s scheduling 
attributes. 


EVALUATION 

Job scheduling under OS has been a problem for many 
shops because the design of that operating system requires 
careful planning on the part of the user to avoid proc¬ 
essing and resource conflicts. Since many users haven’t 
the time to develop an optimum job mix, a good many 
processing delays and wasted resources can occur. 

With Streamline, users are provided with a tool which 
supplies suggested schedules aimed at eliminating most of 
the OS “headaches.” It takes into account run times, job 
dependencies, and resource availability, and produces 
schedules that should permit the user to get the most out 
of his system. And it appears to be relatively fast too. Ac¬ 
cording to the vendor, 1,000 tasks can be performed in 
less than ten minutes on a 360/65. 

Streamline itself does not have a built-in job costing fa¬ 
cility. Tesdata, however, supplies such a job accounting 
package, called Bottomline, as a separate product. 

SUPPORT 

The system is fully warranted against source bugs, and 
updates are provided at regular intervals. The vendor will 
install the system, perform initial training of user per¬ 
sonnel, and provide an additional three days of advanced 
training after the user has had some experience with it. 

Documentation supplied consists of a user’s manual 
and systems guide. 

HEADQUARTERS 

Tesdata Systems Corporation 

7900 Westpark Drive 

McLean VA 22101 
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OVERVIEW 

DAS replaces the read password protection facility of 
OS/360 and 370 with a sophisticated keying technique 
which protects data from destruction and prevents 
unauthorized accesses down to the data set level. 

Written in Assembler, DAS runs on OS/360 or 370 
Release 21 and up (MVT, MFT, TSO, and HASP); special 
versions are also available for Releases 19 and 20, as well 
as MP65. However, DAS does require that its own type 
III or IV SVC be generated into the system. 

DAS is distributed on 800 or 1,600 bpi 8-track tape and 
800 bpi 7-track tape, and consists of partitioned data set 
source and load libraries plus system macros for building 
the DAS SVC. 

« 

The package is offered on a perpetual license for 
$6,500. 

DESCRIPTION 

Data protection, and the methods for attaining it, have 
received a great deal of attention lately as more and more 
companies move towards integrated data bases containing 
sensitive information. To ensure privacy (and placate the 
more paranoid), designers of sophisticated, independently 
vended data base management systems have derived some 
rather ingenious schemes to foil unauthorized eyes. Some 
systems scramble data access keys, some scramble stored 
data, while others scramble both keys and data in an effort 
to devise a palatable — if not foolproof — method of pro¬ 
tecting information. 

While such systems are fine for those who can use the 
accompanying data management facilities, their price and 
operating characteristics make them quite impractical for 
shops needing only the security aspect. That portion of the 
data processing community is left with two options: use 
the data protection capabilities provided by OS, or turn to 
packages like DAS. 

OS Data Protection 

The standard data protection facilities provided by 
OS/360 and 370 consist of four components: the password 
data set, the password maintenance utilities, the read pass¬ 
word interface, and the data set label. 

There is one password data set for the operating system, 
and it cannot be shared between systems. This data set 
(which may itself be password protected) contains data set 
names, their respective passwords, user information, and 
the type of authorization. For a given data set there may 
be multiple passwords with different authorizations. One 
of two types of authorizations may be specified for a pass¬ 
word: read/write or read only. 

With OS Release 21,1 EH PROG M allows the password 
data set to be maintained via the ADD, REPLACE, LIST, 


and DELETEP statements. Additionally, TSO users may 
update the password data set with the PROTECT 
command. 

The read password interface asks for the password 
whenever an attempt is made to OPEN, SCRATCH, 
RENAME, or perform End-of-Volume processing. It 
then scans the password data set for a match on the pass¬ 
word and full data set name, and checks the type of au¬ 
thorization. If the first attempt is unsuccessful, a second is 
allowed; then the program is abended. 

The data set label (or DSCB on disc) contains a flag if 
the data set was protected when it was written or has been 
updated by IEHPROGM. Normally, a data set becomes 
password-protected by the LABEL = („ PASSWORD or 
NOPWREAD) parameter entered on the job control. 
The authorization code, read/write/scratch or read only, 
becomes a part of the data set label, and all subsequent 
references to it are protected. 

The data-protect capabilities of OS are restrictive as 
far as formatting keys are concerned, and they also limit 
the use of Bypass Label Processing and Generation Data 
Sets. DAS eliminates these restrictions. 

DAS Data Protection 

DAS replaces the OS read password function with 
modules that construct a password from information en¬ 
tered in the JCL or during logon, and modules that record 
each successful and unsuccessful access to a password- 
protected data set. The latter information is placed in the 
SMF data set, which is later read by DAS reporting pro¬ 
grams to update the audit file .and report all access 
attempts. 

The data set password is read directly from the job 
queue, and may be constructed from any of the following 
data fields: job name (Log on ID), step name (Log on 
Proc), job accounting data (Log on Acct. Data), step ac¬ 
counting data, DD name, programmer name, program 
name, PARM field data, proc step name (Log on Proc 
Step name), and DSNAME of STEPLIB or JOBLIB. The 
password is constructed under control of a protect code, a 
single character code that may be specified as any position 
in the data fields or as some installation default. 

Up to 256 protect codes may be used, some of which 
will be unprintable. Each protect code keys an in¬ 
stallation-specified code that tells DAS how to construct 
the password. 

The vendor recommends that a Security Officer be as¬ 
signed to establish and maintain the protect codes. In per¬ 
forming this task, he must inspect the JCL to determine 
what types of data sets are in use and how they are used. 
He must also determine which data sets are already pro¬ 
tected by passwords and what other jobs may access those 
data sets that are to be protected. The Security Officer can 
then determine the code that provides maximum 
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uniqueness to restricted-access data sets with the least 
number of secondary passwords for multiple-use data sets. 

Finally, the Security Officer computes the passwords 
for each data set. If step-dependent information is 
included in the password, it should be possible to restrict 
the writing and scratching of the data set to the specific 
steps authorized. 

The password is composed of up to eight characters ex¬ 
tracted from up to eight of the data fields. For example, 
the installation may specify that a password for a particu¬ 
lar data set be made up of the first character of the first job 
account field, the second through fourth characters of the 
program name, the second characters of the third job ac¬ 
count field, and the first three characters of the DD name. 

The key to the protect code becomes part of a special 
DAS SVC (type III or IV) generated and link edited into 
the SYS1.SVCUB. Once DAS is installed, the SVCs must 
be reassembled to change the protect codes. 

DAS also offers facilities which allow users to employ 
Bypass Label Processing (BLP) and Generation Data Sets 
(GDS) but still maintain acceptable levels of security. 
BLP is a valuable processing capability, but it can negate 
the data protection facilities. Thus, many installations 
forbid BLP use where sensitive data is involved. DAS 
allows limited usage of BLP when the specific use is 
preauthorized by forcing the system to assume that any 
data set referenced via BLP is password protected. The 
DSNAME in the JCL then becomes the key, and the same 
protect code logic is used as for any other protected data 
set. The password constructed for BLP data sets is ordered 
differently from that for non-BLP data sets, thus 
preventing the substitution of data sets for other accept¬ 
able protected data sets. (The installation may completely 
forbid the use of BLP by not providing any 
authorizations.) 

When GDG data sets are used in conjunction with the 
standard operating system password facility, two 
problems occur: first, the password facility uses the 
complete 44-byte data set name for a password; second, 
when opening for tape output, the OPEN module requires 
a perfect match of the generation numbers. DAS provides 
a generic password for all generations of a GDG data set, 
and changes the tape output OPEN so that it will check 
only the GDG name without the generation number. This 
latter change allows generation tapes to be cycled, thus 
creating new generations over obsolete versions of the 
same data set. This capability is particularly important 
since password-protected tapes cannot be released to a 
scratch pool because only authorized jobs can write on 
them. 


DAS also allows use of IEHINIT and IMASPZAP, but 
prohibits unauthorized modifications to passwords. The 
former can cause problems because it permits new tape 
labels to be written while totally disregarding the pass¬ 
word protection specified in the label. The latter permits 
any program written at the EXCP level to access the disc 
label and change the password protection code. 

An Emergency Bypass facility is also built into DAS so 
that unauthorized users can bypass the protection facili¬ 
ties under restricted circumstances (e.g., time critical in¬ 
formation is needed immediately). When such requests 
occur, DAS logs them in the SMF data set for later inves¬ 
tigation by the security officer. 

EVALUATION 

The two big questions when evaluating a security 
system like DAS are: Is it breakproof, and is it difficult to 
implement and maintain? The answer to both questions is 
no. 

Any security system can be broken, given a resourceful 
individual with enough time. The greatest deterrents are 
how difficult you make it for the snooper and how great 
the odds that he'll get caught. DAS, with its protect codes 
and passwords constructed for partial data field keys, 
presents a rather formidable problem for the 

unauthorized. In addition, the DAS logging facility, 
whereby all attempts to access protected data are 

recorded, increases his chance of getting caught. 

As far as implementation and maintenance are con¬ 
cerned. users report no serious problems. All have 

followed the vendor's recommendation to use a Security 
Officer, and all stress the importance of that individual's 
role in making DAS go. 

Vendor support is rated quite good; the documentation, 
however, is in the form of a computer printout and is a 
little difficult to read. 

SUPPORT 

The vendor guarantees the system against source bugs 
tor the life of the installation. Although users should be 
able to install DAS by themselves, assistance will be 
provided if requested. 

HEADQUARTERS 

Tesseract 

P.O. Box 7658 

Rincon Annex 

San Francisco CA 94120 
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GENERAL 

AVR-Plus, an enhancement to IBM’s DOS, allows 
users to process a job stream in any partition without 
changing the JCL. The enhancement consists of an auto¬ 
matic volume recognition feature and a device-equate ca¬ 
pability; the former prevents conflicting I/O assignments 
and the latter eliminates the need to maintain duplicate 
JCL for each partition. 

The package runs on any IBM System/360 or 370 
utilizing DOS Release 27 and below. The device equate 
table resides in the supervisor area (but does not add to the 
size of the supervisor itself) and requires 4 bytes per 
equate entered. 

AVR-Plus is available for a 3-year license at a cost of 
$ 1,200 or $90 per month rental. It is offered with Univer¬ 
sal’s DOS ASAP spooling system for $750. A 1 5-day trial 
evaluation is provided. 

DESCRIPTION 

Two of the biggest headaches users of IBM’s DOS 
have had to endure is the lack of an automatic volume 
recognition (AVR) facility, and the need to change JCL 
whenever the user wished to switch job streams from one 
partition to another. The latter problem has been 
resolved with DOS/VS, but AVR is still among the miss¬ 
ing. (Unfortunately, AVR-Plus does not run under 
DOS/VS.) 

For those of you who have opted not to go to DOS/VS 
and wish to make life a little easier and more productive 
for your operators and programmers by eliminating the 
aforementioned headaches, AVR-Plus is well worth 
looking into. 

AVR-Plus consists of automatic volume recognition 
and device equate capabilities. The AVR prevents 
conflicting I/O assignments, while the equate feature 
eliminates the need to maintain duplicate JCL for each 
partition. JCL is completely partition independent, 
thereby facilitating scheduling procedures and mini¬ 
mizing operator intervention. 

AVR allows the user to make assignments to a volume 
serial number rather than to a specific device. AVR 
scans the tape or disc drives for the specified volume and 
makes the required assignment, thus avoiding WRONG 
PACK messages which result in operator intervention or 
job cancellation. In addition, AVR allows for 
premounting of drives and thus reduces job setup time. 

AVR-Plus enables the user to establish a table of 
equates which identifies device assignment relationships 
for each partition. As an example, assume an installation 
has six tape drives numbered 180—185. Drives 
180—182 are to be used by BG and 183—185 by F2. 
An equate table may be defined whereby any assign¬ 
ments to 180 in F2 will be automatically changed to 183, 


assignments to 181 in F2 will be changed to 184, etc. 
The equate table may describe any number of device 
relationships including unit record, disc, and tape 
devices. 

Through the use of device equates, one set of JCL may 
therefore be used for all partitions without concern for 
conflicting I/O assignments. 

Either feature may be used separately if desired. 

Process 

The system consists of about 300 cards and is distrib¬ 
uted in the form of two components ready for cataloging 
into the DOS libraries. About 12 blocks should be 
reserved for the source state library and four blocks in 
the core image library. 

The system is installed in four steps. First, a device 
equate macro (DVCEQU) is cataloged into the source 
statement library. This macro is used to define the device 
assignment relationships for each partition. A maximum 
of 31 equates may be defined for each partition. 

Second, the device equate table is compiled and 
cataloged to the relocatable library. After cataloging, 
any equate entry may be changed by entering an “ex¬ 
tended” ASSGN command through JCL (a card reader 
or console typewriter may be used). Changes can only be 
made for equates defined in the device equate statement. 

Third, the supervisor object deck is cataloged with an 
“ACTION CLEAR” card included in the JCL. 

Fourth, the AVR-Plus object deck is cataloged. 

The equate table is dynamically loaded at IPL into the 
supervisor area. 

AVR allows the user to include a volume serial 
number in the tape and disc ASSGN statements rather 
than specify the physical device address. When an AVR 
ASSGN statement is included for disc, the system scans 
the disc drives searching for the requested pack. When 
found, a message is displayed to notify the operator of 
the allocated drive. If the requested volume is not 
mounted, a console message is displayed which requires 
an operator response. 

When an AVR ASSGN statement for tape is encoun¬ 
tered, the system scans all tape drives which are in a 
ready condition and unassigned in all partitions 
searching for the requested volume. An appropriate mes¬ 
sage is displayed when the volume is found or if an oper¬ 
ator response is required. 

AVR-Plus also provides an ability to find and assign 
unused tape or disc drives which may be made available 
for processing. If this feature is invoked, AVR-Plus will 
make the assignment to a tape/disc drive which is not as¬ 
signed to any partition. 
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AVR-Plus will not check any tape or disc drive which 
is in a “device down” status. Also, a “device inoperable” 
condition occurs if a tape or disc device is defined in the 
Supervisor which does not physically exist on the system. 

Both permanent and temporary ASSGN statements 
are accepted and will be handled accordingly by AVR- 
Plus. 

EVALUATION 

At this point, we usually include our opinions and the 
comments of users regarding the worth and operation of 
the system. However, AVR-Plus is brand new and the 
users have not had enough experience with it to offer 
any enlightening information. 

We feel that the system would be a welcome addition 
to most DOS shops. Aside from the functions it performs 
(which we have discussed thoroughly in the report), 
AVR-Plus provides an additional service which is not so 
obvious: it saves operators the hassle of changing JCL to 


eliminate device contentions, and it saves programmers 
the aggravation of having their jobs kicked back because 
devices are not available. That should be an improve¬ 
ment in any shop’s operating environment. 

SUPPORT 

AVR-Plus comes in the form of an object deck con¬ 
sisting of about 300 cards. The user should be able, ac¬ 
cording to the vendor, to have the system running in less 
than five minutes with no outside assistance. 

Support provided includes a user’s manual and free 
maintenance for the life of the installation. The system is 
also fully guaranteed against source bugs. 

HEADQUARTERS 

Universal Software 
12 Horseshoe Dr. 

Danbury CT 06810 
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GENERAL 

DOS ASAP (Automatic Spooling with Asynchro¬ 
nous Processing) is an automatic spooling system 
for the IBM 360. It operates asynchronously 
with problem programs and acts as an extension 
of the supervisor residing in upper core. 

The system runs on IBM 360/25 (DOS) and up 
with a minimum of 24K bytes of main core stor¬ 
age and requires a minimum 2K bytes of resident 
core for printer/punch support and 3K for print¬ 
er/punch-reader support. Core buffer space is 
user specified, but IK bytes is a recommended 
minimum. Minimum disc storage recommended 
is 10 cylinders of a 2314 or 30 cylinders of a 
2311 depending on the installation. Source lan¬ 
guage is BAL. 

Cost is $3, 500 for the full version, $2, 900 for 
the writer version, $2, 500 for the second user 
location, $1,500 for the third user location, and 
$1, 000 for each subsequent location. Immedi¬ 
ately available. 

PACKAGE DESCRIPTION 

Spooling is a technique that has been used for 
some time to decrease problem program execu¬ 
tion time by intercepting supervisor calls (SVC) 
for unit record devices, and placing the output 
data on a magnetic storage device. After the 
problem program runs to completion, the data is 
retrieved from storage and printed. Quite sim¬ 
ple? Yes. But also quite costly in both auxil¬ 
iary storage space, the amount of time required 
to ultimately print the data, and the overhead in¬ 
curred by having printers and punches sitting 
idle while the data is being spooled. In fact, con¬ 
ventional spooling is so time consuming, some 
packages using it fail to mention print times in 
performance data. 

To counter conventional spooling deficiencies, 
a number of spooling packages have recently 


emerged. These systems generally use the 
same techniques as conventional spooling to 
transfer to and from storage buffers but differ in 
the way they handle i/O commands and store rec¬ 
ords. Most of the newer systems either use 
their own supervisor or modify the host system 
supervisor to intercept SVCs for an output oper¬ 
ation. A SAP appends code to the host supervisor. 

The ASAP logic resides in high core and com¬ 
municates directly with the host supervisor by 
means of branch tables in order to analyze SVCO 
and I/O interrupts. It also uses its own i/O con¬ 
trol tables to identify files and devices to be sup¬ 
ported. ASAP offers an option that allows each 
spool disc file to be associated with as many 
spoolable devices (such as printers and punches) 
as desired, and devices may be interchanged 
within spool files at execution time. 

One of the prominent features of ASAP is its 
ability to output data in printed and punched form 
while the problem program is still being exe¬ 
cuted. This is possible because ASAP intercepts 
the host supervisor calls which control unit rec¬ 
ord entries to the channel scheduler. It also 
generates its own channel command words (CCW) 
and can link these to maximize data transfer. 
Upon examining the PUB at channel scheduler 
time, ASAP determines if the device is one under 
its control. If not, control is returned to the 
system supervisor for execution. 

Data bound for output is transferred to a buff¬ 
er storage area under control of the ASAP logic. 
The number and size of the buffers is specified 
by the user. Should all core buffers be full, the 
data overflows to disc. As each print line is 
stored in core, a switch is tested to determine 
whether the I/O device has already been started; 
thus the first line of data stored in the buffer can 
be transferred immediately to the unit record 
device assigned to that buffer, and each subse¬ 
quent line will be output as the i/O interrupts 
occur. 
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Functional Diagram: DOS ASAP 
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The number of core buffers available for stor¬ 
ing records associated with a spooled device can 
be as high as 20; buffer size is entirely up to the 
user. Each buffer is a fixed length block of vari¬ 
able length lines. Thus for best utilization of 
disc and core and also reduced seek times, one 
would be wise to choose a buffer size that con¬ 
siders both core available as well as efficient 
disc utilization. 

ASAP also offers a forms alignment routine 
which enables print carriage characteristics to 
be conveyed to the spool routine. As lines are 
spooled out, the theoretical position within a 
page is maintained allowing proper handling of 
forms overflow. The forms alignment routine 
permits the perpetual reprinting of one line of 
print, pausing to allow adjustment until the op¬ 
erator is satisfied with the alignment. A printer 
backspacing feature allows reprinting of a page 
in the event of a forms jam. 

The system also permits pseudo devices to be 
defined in the supervisor to simulate additional 
unit record devices which are not physically avail¬ 
able. These devices enable programs to function 
in partitions, and when a device becomes avail¬ 
able the output is spooled to it. 

ASAP is available in two versions: a writer 
system and a full system. The writer version 
spools any number of printers and punches (both 
real and imaginary); the full version has the 
same capabilities as the basic but supports card 
readers as well. All other system capabilities 
apply to both versions. ASAP also fully supports 
COS, CS/30, and CS/40 emulator programs. 


fers an option that allows the user to specify a 
single spool file to be shared by all unit record 
devices or to allocate a spool file for each device. 

In all cases, the address of the physical de¬ 
vice to be used or the device address referenced 
by programs via logical unit assignments must be 
given. The advantage of having more than one de¬ 
vice sharing the same file is that as blocks are 
written to the file for various devices they will 
likely fall in the same cylinder, therefore reduc¬ 
ing seek time which would normally occur when 
more than one spool file is being utilized on the 
same physical disc unit. 

This method can, however, reduce the effi¬ 
ciency of disc space utilization should a low us¬ 
age device not be operational for some reason, 
thus causing its records to be temporarily irre¬ 
trievable. When this happens certain disc space 
beyond the unretrieved records may become un¬ 
available to the high use device until the other 
records are retrieved. 

FEES AND SUPPORT 

The purchase price of the package includes ob¬ 
ject code, documentation, updates, and a lifetime 
guarantee against source code bugs. 

Installation. The vendor will assist with the 
installing, but there are charges for this service 
on a fee plus per-diem basis. Most users, how¬ 
ever, should be able to install the system using 
the implementation procedures supplied by the 
vendor. 


ASAP works equally well in a multiprogram¬ 
ming and nonmultiprogramming environment. It 
does not, however, require a multiprogramming 
supervisor or storage protect features. The 
users we spoke to were extremely enthusiastic 
about ASAP, and confirmed it did operate as ad¬ 
vertised and increased their throughput. Some 
mentioned a few bugs had occurred, but the ven¬ 
dor was quick to correct them. 

Input . Inputs to ASAP consist of data records 
loaded to buffer storage areas contained in core 
and/or on disc. 

Process and Output . During normal process¬ 
ing, routine data transfers cause the ASAP super¬ 
visor to place record data in designated core buff¬ 
ers. If buffer overflow can occur — which is usu¬ 
ally the case in large-volume output programs — 
this overflow must be stored on disc. ASAP of¬ 


Training . Can be provided by the vendor on 
the same fee schedule as installation. This 
should be unnecessary, for the user documenta¬ 
tion is fairly clear and the number of statements 
used by DOS ASAP is small. 

Documentation . Includes a systems program¬ 
mers guide, operators guide, object code, and a 
general information document. The systems pro¬ 
grammers manual is short, to-the-point, and 
provides instructions on how to configure and in¬ 
stall the ASAP system. The operators guide is 
also concise and contains commands necessary 
to operate the system. The general information 
document is sales oriented and stresses the fea¬ 
tures and operational advantages of ASAP. 

Maintenance . The system is fully warranted 
against bugs for the life of the package. Enhance¬ 
ments are also provided free of charge. 
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OVERVIEW 

UCC Two (formerly called DUO 360/370) is a systems 
program from the Utility Division of University Com¬ 
puting, which allows DOS problem programs to run in an 
OS environment, thus availing themselves of OS facilities. 
No reprogramming is necessary. UCC Two operates on 
the IBM System/360 or 370 under PCP, OS/M FT, 
OS/MVT, or OS/VS1. Total storage requirement is 25K 
bytes. 

The Two appends a 1,200-byte DOS SVC filter to the 
OS nucleus. This permits DOS object programs to run in 
an OS partition—and use facilities—by trapping DOS 
supervisor calls (SVCs). 

The Two is offered on a 6-month-lease basis for $ 1,300; 
a 1 -year-lease basis for $ 1,000, or a 2-year-lease basis for 
$800. Maintenance for all leases is free; and 25 percent 
discounts are offered on additional copies of the system. 

DESCRIPTION 

“A DOS to OS conversion! . . . deliver me!” This 
refrain (along with a few unprintable directives to the sug- 
gestor) has become a conditioned response from those 
who have suffered the winters of crippling delays while 
awaiting the promised kiss of springtime—viz., OS facili¬ 
ties in a DOS shop. 

Seriously, a DOS to OS conversion is a pain mainly 
because most installations can’t afford delays while 
production runs are being converted or rewritten. 
Consequently, those shops choosing to go the conversion 
route must allocate portions of their shifts to run the old 
system as backup while conversion is taking place. 

For those sufficiently far enough along in their con¬ 
version to benefit from simultaneous operation of DOS 
and OS, two options exist: the IBM-supplied DOS 
emulator and independently marketed packages like 
UCC’s Two. 

Basically, the Two is designed to allow DOS object 
programs to run in an OS region or partition and to avail 
themselves of OS facilities. DOS jobs, for example, may 
use the OS data management facilities (including 
spooling); all jobs can be read through one job stream 
and processed via one queue; up to 15 programs can run 
concurrently. In addition, DOS and OS jobs can run at 
the same time and processing modes can be switched be¬ 
tween OS and DOS within a single job step. 

The Two, however, does impose a few restrictions: (1) 
It does not support nonrelocatable DOS programs other 
than LUBs and PUBs; (2) BTAM (remote) and QTAM 
are not supported; (3) many time-dependent programs 
are not supported; and (4) DOS ISAM data sets cannot 
be read or created because OS ISAM data management 
facilities are used. DOS ISAM is supported, however. 


Input 

The Two accepts only DOS object programs with OS 
job control. DOS job control must be converted to OS 
JCL, which is both a help and a hindrance. It’s a help 
because you have to be very aware of OS JCL before you 
even use the Two (you don’t with IBM’s emulator). 

Data files used by the DOS programs do not have to 
be converted, except for ISAM and split-cylinder data 
sets. The former have to be recreated under QISAM 
after being dumped by DOS. The latter have to be 
recopied. If you’re running DOS Release 25 or later, the 
Two can use the same ISAM dumped file. 

Process 

The Two appends code to the OS nucleus at SYSGEN 
time. It therefore “modifies” the operating system only 
for as long as that version of OS is being used. This 
approach is consistent with that employed by many of 
the “add-on” packages on the market and neatly side¬ 
steps customer reluctance to use a package which 
modifies the operating system permanently. 

The appended code traps DOS SVCs, converts the 
service requests to suitable OS form, and interfaces these 
requests to OS facilities for action. Since all service 
requests are converted directly by the Two, no modifica¬ 
tions to the DOS programs are necessary. 

EVALUATION 

Since the Two is considered an emulator, you’ll proba¬ 
bly have to evaluate it against the IBM OS/DOS 
emulator, mainly because that package is offered free to 
all System/370 Model 135 through 158 users—except 
those with the Model 155. The IBM offering is not avail¬ 
able to System/360 users, so if you like your machine but 
want OS, you’ll have to go to a package like the Two. 

IBM Emulator Versus the Two 

First, we’ll deal with the OS/DOS emulator. 
System/370 users receive a mixed blessing in the DOS 
emulator. On the negative side is the system degradation 
caused by facilities and resources which must be 
dedicated to DOS. These include fairly large amounts of 
core: 22K plus DOS control program (16 to 28K) and 
partition(s) for OS/M FT; 28K plus DOS CP and parti¬ 
tion^) for OS/MVT. Unless you’re running FI ASP, the 
DOS programs must have discs (except spooled data sets) 
dedicated. You can run three DOS partitions, but by the 
time you’re through allocating core (unless you’re run¬ 
ning under VS), you might just as well have dedicated 
your machine, especially since the DOS emulator does 
not provide storage protection. 

If you want both DOS and OS programs to access an 
ISAM data file, you’ll need two data files—one for each 
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system—if only the emulator is used. If you want to 
print spooled output from DOS you must wait until the 
entire DOS job stream has finished executing, unless 
you’re running under HASP. Last, but certainly not 
least, you must use both DOS and OS job control cards 
for each emulator run. 

On the positive side, the DOS emulator supports 
BTAM as well as various DOS source language compil¬ 
ers, private libraries, sorts, utilities, and MICR. Since OS 
runs the DOS emulator as a job step, OS program steps 
can be mixed in with the DOS executions:, and since suc¬ 
cessive DOS program calls are permitted within a single 
DOS emulator step, DOS jobs can be read through one 
job stream. 

Another plus is that DOS control cards needn’t be 
touched; in many cases only three or four OS JCL cards 
(including delimiters) are required to invoke the DOS 
emulator procedure. 

The UCC Two offers many of the good points of the 
IBM DOS emulator while avoiding many of its limiting 
features. 

The Two requires from one sixth to one half the main 
storage needed by the emulator and makes OS facilities 
available, including more than three partitions, with 
storage protection. In fact, unlike the emulator, it 
provides DOS programs with an OS environment instead 
of recreating a DOS environment. This is especially good 
for shops that do not wish to convert certain fixed 


production runs, that want to stay within the System/360 
line or soften their conversion efforts toward the end of 
the conversion process. 

The Two does not support 1400 emulation (neither 
does the emulator) or some time-dependent programs 
(the interval timer is treated as elapsed time). It places 
restrictions on such events as multitasking, check¬ 
point/restart, and so on, and does not support remote 
BTAM, some DOS source language compilers, private 
libraries, utilities, etc. MICR is acceptable. 

Tape data sets can also be a problem because of tape 
marks (or lack thereof) and the resulting effect of mul¬ 
tifile tapes; because of tape label formats; because of 
duplicate volume serial numbers; and because DOS 
allows its labels to contain special characters, including 
blanks in the first position (OS does not). This restric¬ 
tion, however, could be eliminated by bypassing DOS 
standard labels. 

SUPPORT 

Support includes documentation and free maintenance 
for the life of the lease. 

HEADQUARTERS 

University Computing Company 

P.O. Box 4791 1 

Dallas TX 75247 
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OVERVIEW 

The UCC Fifteen Restart Management System elimi¬ 
nates the manual procedures (and hassle) associated with 
restarting or rerunning a production job. It automatically 
determines the restart job step, purges unwanted data sets 
and restores the OS catalog, and adjusts the generation 
data group (GDG) bias. The Fifteen also works with 
UCC’s Tape Management Software (the UCC One); here, 
the Fifteen will automatically change the expiration date 
on a tape data set uncataloged during a restart operation. 
Moreover, this expiration updating is normally a manual 
process. The Fifteen is also compatible with ASP, HASP, 
and JES III. 

The Fifteen runs on a System/360 or 370 under OS and 
OS/VS, and requires a minimum of 14K bytes of main 
storage; to operate, the Fifteen is link edited into the 
system. This package is written in Assembler Language, 
and is distributed in source code on tape. Currently, the 
Fifteen has about 30 installations. 

The system is offered on a license basis, and is billed as 
follows: 

License Period Fee 

Unlimited $5,000 

3 Years $ 185/mo 

2 Years $200/mo 

1 Year $240/mo 

UCC also allows a 30-day acceptance period. 

DESCRIPTION 

The restart capability, one of the greatest processing 
aids provided by OS and OS/VS, can sometimes be the 
most difficult to use. With it, users can restart jobs halted 
due to a recoverable error; without it, they must rerun 
the job from the beginning. However, once again, restart 
can be very difficult to use. 

While the OS facility allows restarting from a 
programmer-defined checkpoint or specific step name, it 
has no provision for automatically correcting the OS 
catalog nor does it reset GDG bias numbers. 
Consequently, jobs running after a failure may be using 
incorrect data sets (if they don’t blow-up first). A restart 
under OS requires a good deal of familiarity with the 
problem job. To restart, the user must first determine a 
restartable job step; then, he must correct (reset) the OS 
catalog; next, unwanted data sets created by the “down” 
job must be scratched; and finally, he must readjust the 
GDG bias. In addition, the JCL must be fixed. (The 
latter should prove an interesting exercise for operations 
people not familiar with JCL.) 

The Fifteen provides solutions for all of these 
problems. Determining the restart job step, for example, 
is handled by an internally stored, user-specified list of 
restartable steps. To restart, a symbolic keyword 


parameter is supplied in the EXEC statement to specify 
the processing code and the names of the job steps where 
execution is to begin and end. No other changes to the 
JCL are required. 

Correcting the OS catalog and scratching unwanted 
data sets (both direct-access and single-volume, un¬ 
cataloged, direct-access data sets specified by volume 
serial number) are handled automatically. Data sets on 
tape are managed by UCC One. If a tape data set is un¬ 
cataloged during restart, and there is only one data set on 
the tape, and the job name is the same one that created 
the data set, then the Fifteen will change the expiration 
date in the Tape Management Catalog (TMC) to the 
default period specified when the TMS was installed. 

Adjusting the GDG bias — a rather hairy exercise 
under OS — is also handled automatically by the Fif¬ 
teen. OS is designed so that GDG bias numbers are rela¬ 
tive to the beginning of the job; however, restart capabil¬ 
ity is desired at the job-step level. To eliminate this 
problem, some computer installations have modified OS 
so that the relative generation bias returns to zero at the 
end of each job step. The Fifteen automatically changes 
the GDG bias relative to either the job or job step 
depending on the option selected by the user. A more de¬ 
tailed explanation of how this works is contained in the 
next section. 

PROCESSING 

To implement the Fifteen, a special job step, showing 
the PARM, start step, end step, and region, must be ex¬ 
ecuted as the first step of each production job. The 
PARM statement allows the user to specify how data sets 
will be handled in the event of failure. This information 
is held in the Catalog Management Table. In some cases, 
the data set will be allocated but not cataloged; in others 
it will uncatalog the data sets so that they may be 
recreated. 

The GDG bias problem, previously described, can be 
handled relative to the job or job step. The user chooses 
between the two when he specifies the primary entry 
point where the Fifteen is link edited. When the installa¬ 
tion uses the GDG bias at the job-step level, bias 
numbers are reconstructed relative to the job. During 
restart, the Fifteen assumes that the bias numbers in the 
JCL are correct. If the job level is selected, the bias is as¬ 
sumed to be correct during processing. During restart, 
the bias number is altered in the job queue so that it will 
be correct for the restart. 

The UCC User’s Guide provides a beautiful example 
of how OS catalog updating and bias handling are ac¬ 
complished. It assumes that a two-step job is running. 
Step 1 has two input data sets: an activity tape (data set 
A), which is used to update a generation data group, and 
(index B, generation 35). Step 2 also has two output data 
sets: a work tape (data set C) and the update generation 
data group member (index B, generation 36). Step 2 uses 
both output data sets from Step 1 to produce data set D. 
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Assume, for this example, that the OS catalog is used 
for all data sets, that all are tape data sets, and that all 
output requests are nonspecific; i.e., the operator will be 
requested to mount any scratch tape. When this job is ex¬ 
ecuted, the following normal OS conditions must exist: 

• The highest cataloged generation number for data 
set B must be 35. 

• Data set A must be cataloged. 

• Data sets C and D must not be cataloged; thus, they 
can be created and cataloged. 

When the job is executed for a normal production cycle, 
the Fifteen will record the generation number (36) for 
the output of Step 1 and then attempt to uncatalog data 
sets C and D. (If data sets C and D were on disc, a 
scratch attempt would have been made before the un¬ 
catalog attempt.) 


If the job must be restarted at Step 1, the Fifteen will 
uncatalog data sets C and D, plus generation 36 of GDG 
B. If the job is restarted at Step 2, only data set D is un¬ 
cataloged. Notice, however, that another problem exists. 
The DSNAME for the GDG in Step 2 is B( T 1). This 
condition is only correct when Step 1 is also executed in 
the same run. The Fifteen will change the input DS¬ 
NAME from B( -F 1) to B(O). It will also prevent Step 1 
from executing. If only Step 1 is to be rerun, the Fifteen 
will uncatalog data set C and generation 36 of GDG B. 
It will then prevent Step 2 from executing. When a 
subsequent production cycle is executed, the Fifteen will 
record the Step 1 output generation number 37, which 
will permit restart of this production cycle, if necessary. 


Installations using ASP, JES III, or any FIASP setup 
facility will experience setup requests for individual jobs 
based on the current contents of the system catalog. 
These requests will be invalid for restart purposes 
because they represent the output serial numbers and 
generation numbers of the prior unsuccessful run, and 
the catalog at job initiation will not have been modified 
by the Fifteen. The setup facilities are embedded in the 
initiation procedures prior to the first job-step execution. 
In addition, the setup facilities make no allowance for 


partial rerunning of the job and may ask for a setup on 
steps not to be executed. 

To circumvent these setup problems, the PRERMS 
program can be used to modify the ASP, JES III, or 
HASP setup procedure. The PRERMS module will set 
the catalog back to the proper level for restarting the job 
and set parameters in the CMT header record to indicate 
the necessary parameters for restart. 

EVALUATION 

As mentioned previously, restarting a job under OS 
requires a fair amount of technical skill, a good amount 
of patience, and a lot of time. In many cases, the 
programmer who wrote the job and the group JCL spe¬ 
cialist must also get involved — thus wasting their time 
too. 

The Fifteen provides a rather simple solution to some 
rather nasty problems. Also, it is fairly cheap considering 
the personnel time and job reruns it saves. Users inter¬ 
viewed have had the Fifteen for almost 2 years, and 
agree that it does everything UCC claims. They also 
have nothing but praise for the technical competence 
and cooperation of vendor personnel. Judging by all in¬ 
dicators, the Fifteen looks like a good buy. 

SUPPORT 

The Fifteen is distributed on tape, along with a sample 
set of JCL. While the user is responsible for installing it, 
he is aided by simple implementation instructions. 

Updates and repairs are provided by‘phone or mail. 
Maintenance is free for the life of leased systems; 
purchased systems are maintained free for the first year. 
Thereafter, a maintenance contract is available. 

HEADQUARTERS 

University Computing Company 

P. O. Box 47911 

Dallas TX 75247 
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VALUE COMPUTING 
Systemlll and Data Center Scheduler 


OVERVIEW 

The System III Scheduling System and the Data Center 
Scheduling System, are two separate but upward compa¬ 
tible utility programs that provide a simple but comprehen¬ 
sive solution to the workload scheduling problem. System 
III handles schedule development for a single processor; 
the Data Center Scheduler handles schedule development 
for multiple processors, plus other concurrent and noncur- 
reijt work stations. 

Typically, both schedulers produce a schedule encom¬ 
passing a 24 hour work period. The schedules list, in start¬ 
time order, the jobs to be done, and account for such vari¬ 
able operational scheduling factors as: predefined earliest 
start/latest completion times, inter-job predecessor/suc- 
cessor relationships, core requirements, data set conflicts, 
and job frequency characteristics. Both packages also 
allow dynamic schedule revision that provides for changes 
necessitated by unanticipated job demands. They provide 
various forms of post-operation summary information 
such as actual versus scheduled operation fhne, CPU and 
core utilization, pooled device, shift, kind-of-run, and 
paging reports. Both packages thus not only serve as 
schedulers, but also provide comprehensive monitoring 
facilities. 

System III runs on the 360/70 series and carries a pur¬ 
chase price of $11,000 or $1,010 per month on a 12-month 
lease for the DOS and DOS/VS versions. The OS and VS 
versions carry rates of $14,000 purchase and $1,285 
montly lease. 

The Data Center System Scheduler runs on both the 
360/370 series and on the Burroughs B6700 and B7700 In¬ 
formation Processing Systems. The DOS and DOS/VS 
versions sell for $18,000 or can be leased for 12-months at 
$1,650 per month. The OS and VS versions carry rates of 
$20,000 purchase and $1,835 montly lease. 

DESCRIPTION 

Both System III and the Data Center Scheduler System 
are essentially utility packages. They both produce work¬ 
load schedules for a defined job set based on various con¬ 
ditional parameters. These parameters include such factors 
as the latest time a job must complete; the various jobs that 
must have completed prior to the start of a given job; the 
priority of a job within the overall operation; the fre¬ 
quency with which the job is executed in terms of day of 
month, day of week, week or month of year, etc.; core and 
data set requirements within a job set. They can both pro¬ 
duce, in addition to the daily schedule, various reports 
from SMF data, including core and CPU utilization statis¬ 
tics in a highly readable and useful format; a summary re¬ 
port on shared/pooled devices pinpointing individual 


usage on a daily, weekly, monthly, quarterly, or annual 
basis; a shift report on the same periodic basis for CPU 
time of all jobs runs, OS and system wait time, and actual 
processor usage; total job statistics including elapsed time, 
and percentage of total throughput for each category of 
job; paging information relative to paging in and out, and 
reclaim rate. 

The two schedulers differ primarily in the level of sched¬ 
uling each does. System III produces schedules for a single 
processor. The Data Center Scheduler, as the name 
implies, is capable of scheduling virtually all equipment in 
the data center, including multiple processors, peripheral 
operations, and support activities. Both schedulers are 
built on a common base, so the Data Center Scheduler can 
be viewed as a superset of System III. This has obvious de¬ 
velopment advantages for the vendor but, more impor¬ 
tantly, indicates the user’s ability to “step up” from a Sys¬ 
tem III to the fullblown package with virtually no disrup¬ 
tion in the installation’s scheduling practices. 

Both packages are made up of several functional ele¬ 
ments including: 

• System I — a statistics gathering and reporting 
function through which job and system descriptions 
are entered. The accumulated information forms a 
data base called the workload control file. This file 
represents an inventory of a user’s resources, including 
available hardware, operating systems used, and the 
characteristics of each production program. 

• The Daily Scheduler Program — the actual scheduling 
program that exercises VCI’s scheduling algorithm 
against the data base. The module accepts input 
instructions describing the schedule start and end time, 
the system to be scheduled, and the work to be per¬ 
formed during the scheduled period. While both 
System III and the Data Center Scheduler use the same 
basic set of input instructions, the DCS also includes 
instructions relative to machines to be scheduled, pri¬ 
mary and secondary processors, shared devices, and 
job/machine interchangeability. 

• Revision Scheduling — a module that allows dynamic 
schedule revision from defined revision time points for 
the last schedule generated. 

* 


HEADQUARTERS 

Value Computing Inc. 
300 VCI Building 
West Marlton Pike 
Cherry Hill NJ 08034 
(609) 429-4200 
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• 31 Day Scheduler — a module that produces a detail 
run analysis for a 31-day period. It provides a 
summary of each day’s expected running times and 
usage statistics based on data contained in the Work¬ 
load Control File. 

• Daily Actual Versus Schedule Report Program — this 
is actually a subprogram of System I. It provides 
detailed reports on overall execution times and on run 
time details of the individual jobs. 

With the information provided by the two schedulers, a 
user is assured that the available equipment is being used at 
optimum rates in terms of the work to be done. In 
addition, he can optimize the utilization of operations 
personnel, including operators, keypunchers, clerical and 
administrative staff. Several of the statistical outputs can 
be applied to both short- and long-range equipment 
replacement planning, and to production program 
enhancement. 

PROCESSING 

The standard scheduling run involves two major data 
elements — the Workload Control File and the immediate 
scheduling parameters. The WCF data base is built via 
complementary methods of SMF data sampling by System 
I procedures and job input descriptions entered through a 
separate WCF maintenance function of System I. The 
immediate scheduling parameters are submitted to the 
daily scheduler program and describe, in effect, the WCF 
data to be used in the scheduling algorithm, plus the hard¬ 
ware/software environment. 

The WCF contains two prime units of information — 
run model records and job stream records. Typically, the 
basic data for the records is constructed from sampled 
SMF data that has been accrued over some period of time 
meaningful to an installation’s standard operations cycle. 
The data thus accumulated is supplemented by direct 
input. In the case of run model records, direct input 
includes information that defines as a minimum, the core 
size, run time, and CPU utilization factor of the run to be 
scheduled. Additional data input may include predecessor 
relationships between runs, early start and late finish time, 
priority status, and operations cycle frequencies associated 
with a given run. A calendar can also be constructed within 
the WCF that defines the various workday and calender re¬ 
lated frequency codes associated with repetitively cycled 
runs. In the case of job stream records, direct input de¬ 
scribes either job streams as such that must be scheduled 
serially, or collections of jobs that are constrained for 
scheduling purposes only by their own individual job re¬ 
strictions. 

The immediate scheduling parameters entered into the 
daily scheduler program identify the schedule start and end 
times, the system to be scheduled, and the work to be per¬ 
formed during the scheduled period. Individual runs, 
streams or collections may be scheduled and temporary 
changes made to various elements of the run model 
records. This dynamic change feature provides the user 
with wide latitude in that it affords him a means of ac¬ 
counting for special situations that affect predefined 


scheduling constraints.Typical of the keyword functions 
that can be used on this basis are instructions that modify 
automatic frequency scheduling for a defined run, modify 
predecessor relationships, and invoke a scheduler priority 
feature that forces all jobs designated as priority in the 
WCF to be scheduled first. 

The combination of the Workload Control File data base 
and the immediate scheduling parameters are plugged into 
the mathematical algorithm, which exercises a sophisti¬ 
cated linear program to produce a job schedule that can ac¬ 
complish the defined workload in the shortest elapsed 
time. 


Output 

A variety of outputs are developed by the schedulers that 
define not only the schedule itself, but also information 
relative to the runs scheduled and post-schedule summary 
data. These include: 

• Load list, which is a list of all runs requested for sched¬ 
uling and an error list.During scheduler processing, 
each run is assigned a unique ID by which it is identi¬ 
fied in subsequent lists and which it retains through the 
scheduling day. 

• Status report, which summarizes all runs in the sched¬ 
ule and lists their various scheduling constraints. It 
includes column headings for; run name, minor appli¬ 
cation code, device classes and number of each, ear¬ 
liest start time, latest completion time, run time, core, 
CPU PCT, ID number, predecessor of this run, and 
partition, paging, and configuration requirements, if 
applicable. 

• Schedule summary report, which provides a detailed 
listing of all jobs scheduled. It is organized in 5-minute 
increments and reflects the system state for that inter¬ 
val, including run mix, utilization, and remaining 
device resources. It also includes error information re¬ 
garding jobs that could not be scheduled because their 
predecessor could not be scheduled, unresolvable 
device or data conflicts, excess devices needed, or in¬ 
sufficient time in the scheduled period. 

• Schedule summary report, which provides an alpha¬ 
betical cross-reference to the schedule summary report 
and status report. It includes column headings for run 
name, ID number, start time, machine, run time, and a 
comments column. 

The WCF information is also listed in a formatted, 
highly readable form that includes the following data or 
headings, run name, run application, core requirements, 
run time, early start, late finish, device information for 
both class and number of units, the run’s frequency codes, 
all predecessor runs, CPU utilization as a percentage, and 
various data related to machine requirements, partition, 
and configuration. 

Revision scheduling output follows the same general 
output lines as for the basic scheduler. However, jobs that 
have been eliminated will be reflected in the schedule sum¬ 
mary report and an “elim” notation. 
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The 31-day Scheduler outputs both a schedule summary 
and a system summary. The schedule summary provides an 
exact image of the output described above for WCF 
listings for jobs having frequency codes corresponding to 
the day of the period. The system summary report lists 
daily requirements for total run time, average core usage, 
total number of runs, and device usage and utilization. 

The post-operation day processing of the system man¬ 
agement facility data by System I produces the actual- 
versus-schedule report, a sample of which is shown in 
Figure 1. The report also includes a one-page summary 
that lists: on time deadline jobs, late deadline jobs, non- 
scheduled jobs run, scheduled jobs not run, abended 
scheduled jobs, number of jobs in the original schedule, 
total jobs run, total schedule time, and total actual time. 

EVALUATION 

Both packages have a relatively wide distribution — 90 
copies of System III and 25 of the Data Center Scheduler 
have been sold since their introduction. And, most impor¬ 
tantly, the users all feel that they made a good buy. Vir¬ 
tually all users interviewed were ecstatic about their parti¬ 
cular package and offered comments that ranged from “a 
fantastic system and even better support” to “we utterly 
depend on it” to “it’s saved us a small fortune in labor and 
equipment rental costs.” This last comment proved to be 
very interesting and was made by more than one user, 
especially regarding equipment rentals. 

Although not necessarily obvious, both packages have 
an implicit usage as system or center workload simulators. 
By providing projected system loadings and their fre¬ 
quency and usage characteristics, the packages can be used 
to predict future equipment requirements or to delay de¬ 
livery or, as one user did, to demonstrate that 6,250 bpi 
density tapes were not cost-effective for his shop and did 
not, in fact, optimize any loading factors for his workload. 


Needless to say, not only was a significant amount of 
money saved, but the aggravation of realizing that the new 
gadget was a bomb was avoided. Additionally, several of 
the users have applied the simulation technique to very 
long-range planning and software modification. 

As already indicated, the package runs on the 370 under 
various versions of the operating system and can provide 
job scheduling for any piece of gear that can be described 
to it. One user in particular schedules 15 mainframes and 
seven other workstations. The mainframes range from a 
370/158, a 7074 (yes, there are some that are still alive and 
apparently well), RCA 501s and 301s, RCA System 6s, 7s, 
to a Univac 70/45, plus decollators, print distributers, and 
data entry facilities. Another schedules two 158s, a 168, 
and his HASP operation. Several users have replaced their 
own in-house packages with either System III or the Data 
Center Scheduler System. 

After reviewing both packages and discussing their or¬ 
ganization and usage with the developer, the user com¬ 
ments were not unexpected. They are both well thought out 
solutions to a very thorny problem and well worth the cost. 
In fact, it probably would be better to say that they are 
worth the price, because in many installations the cost will 
very likely diminish to the vanishing point. 

SUPPORT 

The vendor provides a maintenance and enhancement 
program at a cost of $1,320 and $1,680 for the System III 
package under DOS-DOS/VS and OS-VS, respectively. 
Similar charges for the Data Center Scheduler System are 
$2,000 and $2,150. 

From all indications, the vendor is very responsive to his 
customers’ needs and provides both installation assistance 
and package modifications to enhance operations within a 
given facility. 
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Figure 1. Actual Versus Schedule Report 
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OVERVIEW 

VISAM (Variable Length Indexed Sequential Access 
Method) is similar in function and use to the IBM ISAM 
(Indexed Sequential Access Method). It is a true variable 
length access method that, while observing all of the 
standard ISAM conventions and console messages, offers 
improved processing throughput and more efficient 
utilization of disc storage. 

The system runs on an IBM System/360/370 operating 
under DOS. It requires only 1.5K bytes per program. Pe¬ 
ripherals include disc storage and a card reader (or com¬ 
parable device) for input. 

VISAM running on the 2311/2314/2319 can be 
purchased for $5,000 or on the 23 1 1/2314/23 19/3330 sells 
for $6,000. VISAM with the 3330 and CICS can be 
purchased for $8,000. Delivery schedule for VISAM is 
immediate. 

ISAM SIMILARITIES 

VISAM similarities to ISAM are in the VISAM master 
index and cylinder index which are identical in form and 
use to the ISAM indexes. The VISAM track indexes, 
created at file load time, are similar to those created by 
ISAM and serve the same function as ISAM in locating 
the proper data track within cylinder. Unlike ISAM the 
track indexes are not used to locate overflow records; 
once created in a load operation, they also are never al¬ 
tered. 

The use of cylinder index in core is available under 
VISAM and offers an additional function of compression. 
Compression is done left to right and reduces the number 
of bytes necessary to hold the cylinder index. VISAM im¬ 
perative macro functions are similar to those available 
under ISAM except where variable record length and 
overflow considerations apply. VISAM files may be 
loaded, retrieved sequentially and/or randomly, updated, 
and added to. 

In addition, the use and checking of DLBL and EX¬ 
TENT cards defining the prime data area is identical to 
ISAM with the exceptions in the VISAM job control. 

VISAM Differences 

There are 10 major differences between VISAM and 
ISAM. For instance all VISAM logical records are vari¬ 
able in length and contain a four byte length field as the 
first four bytes of every logical record. These records may 
be expanded and contracted by PUTs and WRITES at any 
time during the life of the file. New records of varying 
langths may be added to the file at any time by a WRITE 
NEWKEY. These variable length logical records may be 
blocked in both the data and overflow areas up to a full 
track. A fixed-length physical block approach is used 
which fixes the length of the physical block at file-load 


time and establishes the maximum length of the logical 
records at blocksize minus nine bytes. 

All logical overflow records reside in a blocked envi¬ 
ronment in an independent overflow area. Cylinder 
overflow areas are not provided. Rather, it is defined by a 
separate DLBL and EXTENT card set, and overflow 
records are chained to their originating block, instead of 
the data track as in ISAM. This technique, along with 
blocking of overflow records, provides greatly improved 
performance on record insertion and expansion opera¬ 
tions and eliminates the need to alter track index records. 

In addition, a logical record deletion facility is provided 
that allows VISAM to delete a record immediately and 
reclaim the room that record formerly occupied. The 
complete file statistics are maintained by VISAM and 
displayed at the user’s request through the STATCS op¬ 
tion in the DTFVI. 

VISAM does not allow a file to be extended. The same 
net result, however, can be achieved with no sacrifice in 
performance by using the WRITE NEWKEY macro to 
add records to the end of the file. 

Other differences in VISAM are that the equivalent of 
the idname operand of SET L is not provided and the end 
of file exit address is provided as a DTFVI option. An 
error exit address is also provided as a DTFVI option 
(ERREXIT = ). This feature provides for implementa¬ 
tion of a centralized error handling routine. 

With VISAM, the WAITF macro is not required. It 
may be included in a VISAM program for compatibility 
purposes, but it performs no function. The VISAM file 
security and restart facilities are provided through the 
use of CHKV macro and the UPEXIT operand in the 
DTFVI. 

Under the load function, there are no input/output 
changes required with VISAM. However, under any 
other situation such as in the overflow area, one change 
is required for double buffering. In the overflow area, 
two changes are required on adds or updates to replace 
ISAM I/O area L. VISAM can be used in batch and on¬ 
line environments. 

FUNCTIONAL DESCRIPTION 

The VISAM file consists of two independent but 
closely related areas. One is the prime data area and the 
other is overflow area. Both areas are created during a 
VISAM load function, and both must be present for any 
other file processing. Although the two areas make one 
file, each area requires its own unique set of DLBL and 
EXTENT cards. 

The DLBL and EXTENT job control formats corre¬ 
spond to System/360 DOS specification. Certain VISAM 
specifications are necessary for VISAM functions, howev¬ 
er. For instance, the DLBL “file-name” used for the prime 
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data area must be suffixed with the letter I and the DLBL 
“filename” used for the overflow area must be suffixed 
with the letter O. 

Prime Data Area 

The DLBL file code used for the prime data area must 
be either ISC for load or ISE for any other file processing 
and the file code used for the overflow area must be DA. 

Another specification is that the EXTENT types for the 
prime data area must include a type 4 (cylinder index 
area) and a type 1 (data area). The third EXTENT is per¬ 
missible and required if the master index option is being 
used. The extent type 2 (independent overflow) is not 
allowed under VISAM operation. The EXTENT type for 
the overflow area is type 1 (data area), and the area 
defined must not overlap the EXTENT specifications for 
the pfrime data area. 

With VISAM neither the prime data area nor extents 
may be defined as split-cylinder and the EXTENTS used 
for the master index (if used) and cylinder index must be 
contiguous with each beginning on a cylinder boundary. 
For example, if a master index is used and occupies cylin¬ 
der 2 then the cylinder index must reside in cylinder 3 
through x. The EXTENT(s) used for the data portion of 
the prime data area (type 1) must begin on a cylinder 
boundary (track 0). Only one data area extent per pack is 
allowed. Data area extents defining a multipack file must 
be contiguous from pack to pack with the upper limit of 
one ending in the last track of cylinder 199 and the lower 
limit of the next pack extent beginning in track 0 of cylin¬ 
der 1. The overflow area is limited to a single EXTENT 
but this extent need not be contiguous with other extents 
nor reside on the same pack as any of the other extents. 
The overflow area extent must begin on a cylinder bound¬ 
ary. 

It should also be noted that the LBLTYP card defining 
the maximum total number of EXTENT cards used with a 
single VISAM file must be included at link edit time with 
any program using one or more VISAM files. 

Logical Record. Every VISAM logical record must 
be created or accessed with particular regard to VISAM 
requirements. The four requirements are: bytes 1-2 are 
reserved for the logical record length. The record length 
must be in binary format and cannot exceed the BLK- 
SIZE entry in DTFVI less 9, nor be less than the 
KEYLEN entry in the DTFVI plus 9. The user must 
specify this record length if creating or adding logical 
records and alter this logical record length if he is up¬ 
dating existing logical records with an increase or 
decrease in record length. 

The bytes 3-4 are reserved for future VISAM expan¬ 
sion and must always be binary zeros. Byte 5 is also 
reserved for VISAM and must always be set to binary 
zeros during a load create or add operation. During a 
VISAM update function bit 0 of byte 5 is reserved for 


the user. If bit 0 is turned on during a PUT or WRITE 
operation, the logical record will be immediately deleted 
from the file. 

Bytes 6 through the end of the logical record are 
reserved for the user. However, each logical record must 
contain a Key area to house the logical record key. The 
DTFVI entry KEYLOC specifies the beginning location 
of the Key field in the logical record. The minimum 
position is 6. The length of the Key field is specified by 
the DTFVI entry KEYLEN. The maximum length is 
256. It is the user’s responsibility to build or create the 
Key as specified during a create or add operation and 
maintain the same KEYLEN and KEYLOC specifica¬ 
tions for the life of the VISAM file. 

Before a VISAM file can be processed, it must be 
defined to IOCS by the DTFVI declarative macro. After 
defining the file, the user can process the file with the 
imperative macros. The file must be initialized, 
processed, and deactivated just as any other file opera¬ 
tion under IOCS. 

Definition. The VISAM file must be defined by the 
DTFVI macro, which uses a series of keyword operands 
to describe the particular characteristics of the file. In 
initializing the file, the OPENV macro must be issued 
before any other VISAM imperative macro. This is true 
for any file function (load, retrieve, or add). The 
OPENVR macro performs the same functions as the 
OPENV with the addition that all DTFVI address con¬ 
stants are relocated. 

Other macros include processing the file for loading, 
accessing and adding, and deactivating the file. 

The CHKV macro (protecting the file) allows the user 
to insure the integrity of the file up to the current 
moment. 

The VISAM file statistics report is printed on either 
SYSLOG or SYSLST upon the issuing of the CLSEV 
macro, if the operand STATCS = SYSLOG, or if 
SYSLST is specified. This report provides the user with a 
variety of file statistics which he can employ to analyze 
the efficiency with which he is using disc. A timing is 
also provided giving the duration of VISAM operation 
during a given job. 

The report is intended to aid the user in organizing his 
file. One example of such an analysis might be an exami¬ 
nation of block size statistics. Another useful statistic is 
the number of bytes needed for cylinder index in core 
which is calculated at file load time. 

EVALUATION 

Users reported that VISAM contained several bugs; 
however, most were minor and the company worked them 
out as soon as they were notified. VISAM when bench- 
marked against ISAM is reported to run from 40 to 60 
percent faster than ISAM. 


80 





AUERBACH Guide to_ 

OPERATING SYSTEM ENHANCEMENTS 


Users have found several ways to use VISAM in addi¬ 
tion to using it as the direct replacement for ISAM. One 
company is using it as part of a complete data base system 
with CHAM. All in all, the users found no problems with 
VISAM. 

SUPPORT 

The purchase price covers installation, documentation, 
and maintenance. The supplier provides 1 -day training on 
initial installation. Documentation includes a user manual 
which contains sample programs and describes all macros 
and performance considerations. 

Users are provided with 60 days of support to correct 
bugs in the package. Maintenance contracts are available. 

HEADQUARTERS 

Weiland Computer Group 
4825 North Scott St. 

Suite 72 

Schiller Park IL 60176 
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OVERVIEW 

The Virtual Disk Utility System and the Dump/Re¬ 
store/Plus Programs are designed for fast, reliable, and 
easy-to-use backup of extensive disc storage. These pro¬ 
grams provide disc copy (COPYDD), disc-to-tape dump 
(COPYDT), tape-to-disc restore (COPYTD), and a stand¬ 
alone restore program called SAVER. 

The programs run on an IBM 360/22 and up or any ver¬ 
sion of System/370 operating under DOS or DOS/VS. 
Depending on the operations to be performed, they 
require one disc, one tape, one card reader, one printer, 
and a console. Core requirements vary with the disc 
device used. Table 1 illustrates partition size 
requirements. 

Table 1. Partition Size Requirements 




Partition 

Program 

Device 

Size 

(bytes) 

Disc to Disc 

2311 

14K 


2314 

16K 


3330 

22K 


3340 

18K 

Disc to Tape 

2311 

14K 

2314 

18K 


3330 

24K 


3340 

20K 

Tape to Disc 

2311 

14K 

2314 

18K 


3330 

24K 


3340 

20K 


DESCRIPTION 


The utility programs contained in this package enable 
a user to dump multiple files and/or volumes from disc- 
to-disc and restore entire tapes or selected files/volumes 
to disc. COPYDT enables a user to dump any combina¬ 
tion of files (sequential, index sequential, or direct 
access) or entire volumes (normal or 1401 double disc) 
to tape during the same run. The Virtual Disk Utility 
also supports VSAM files and permits files to be 
renamed. 

COPYTD restores files and/or disc volumes from the 
tape created by the COPYDT program. Restored files 
and disc volumes are completely verified. When an en¬ 
tire volume is restored, the program checks that the vol¬ 
ume being restored has the same serial number as the 
dumped volume. ISAM files may be reorganized and all 
files may be relocated with the exception of those files 
with physical track addresses. 

COPYDD allows the user to copy an entire disc vol¬ 
ume, any type of file (sequential, direct access, or index 
sequential), or copy any portion of a volume by cylinder 
and head extents from one disc to another. Any type of 


file other than a system residence file can be relocated 
during the copy phase and can be used from its new loca¬ 
tion as long as it does not contain any physical disc 
address pointers. 

SAVER is a stand-alone program which provides a re¬ 
liable method of recreating a user’s system residence vol¬ 
ume from tape if his current operating volume is ren¬ 
dered inoperable by a hardware or software error. By of¬ 
fering the user a tape backup capability, SAVER elimi¬ 
nates the cost of keeping the backup system residence 
volume on disc. A system residence volume can be com¬ 
pletely restored from tape-to-disc including verification 
in less than 20 minutes. 

These programs are self-relocating, and their run time 
depends on channel use, partition size, disc drive, and 
tape speed. They also accept any data that can be placed 
on the devices involved, including spanned records. The 
user need not specify record or block length for any disc 
volume or file to be dumped or copied. 

PROCESSING 

Input 

COPYDT accepts multiple data cards from the card 
reader or the console. The card contains file names and 
the system numbers of volumes to be dumped. Multiple 
files and/or multiple disc volumes can be specified on the 
same control card. All file names must indicate the type 
of data organization: SD for sequential, DA for direct 
access, or IS for index sequential. 

If label information for files is not in the standard 
label area, label and extent cards must be supplied for 
each file to be dumped. 

Data cards are optional for COPYTD and are used to 
restore only specified files and/or disc volumes contained 
on the tape; they are not required if the entire tape is to 
be restored. When used, they can be input by way of 
card reader or console, and must contain file names and 
appropriate numerical identifiers for all files and vol¬ 
umes to be restored from the tape. These names and 
numbers must be identical to those used for the dump. 

If label information for files is not in the standard 
label area, label and extent cards must be supplied for 
each file to be restored. The extent information must 
match that of the original files. 

COPYDD accepts multiple data cards containing the 
serial numbers of the input and output discs. These cards 
can be supplied from the console or the card reader. 

The SAVER program accepts as input the system resi¬ 
dence tape or any other tape which is to be restored in a 
stand-alone mode created by the COPYDT program. 
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Process 

The object decks supplied contain the control cards 
necessary to catalog the programs to the core image 
library. When one of the programs is to be executed, it 
determines the disc device type and alters itself to handle 
that disc. In addition, each program automatically ascer¬ 
tains the size of the partition in which it is operating and 
allocates its use of core accordingly. The Virtual Disc 
Utility automatically determines the number of tape I/O 
areas depending on core available. 

When the COPYDT program is used to dump data 
from a disc to a tape, files are opened and all the data in 
the volume is dumped. COPYDT saves the volume serial 
number so that it is available for checking during a 
subsequent restore operation. If 1401 double discs are in¬ 
volved in the dump, COPYDT ascertains whether the 
volume has been initialized for this purpose. 

To restore files from tape to disc, the COPYTD pro¬ 
gram opens the tape files that are to be restored. Before 
the process begins, COPYTD checks the serial numbers 
of the volumes to be restored against the numbers of the 
volumes on which they will be written. If they match, all 
data is restored; otherwise, the operator can retry the 
check, ignore the difference in serial numbers, or cancel 
the job. When restoring files, the user can indicate that 
the process is to start with the first reel or any other reel. 
If only selected files are to be restored, the user must in¬ 
dicate them on the data control card; otherwise the card 
is optional. 

The COPYDD program performs the 1401 double¬ 
disc compatibility check if required and verifies that the 
serial numbers of the volumes to be restored match those 
contained on the data card. The program cancels if a 


match is not found. When a match occurs, COPYDD 
copies everything on the input disc onto the output disc. 
Both devices maintain their original volume serial 
number. 

SAVER completely restores the file or volume created 
by the COPYDT program. This is done in a stand-alone 
environment. 

Output 

In addition to the dumped, restored, or copied files, 
these programs print diagnostic messages when errors 
occur. 

SUPPORT 

The lease price includes documentation and 1-year 
maintenance. Each user is responsible for installing the 
programs according to installation instructions supplied 
by Westinghouse. No training is necessary. 

Documentation in the package includes program ab¬ 
stracts, program descriptions, operations manual, pro¬ 
gram object decks, and optional source code on tape. 

The supplier guarantees the programs will function ac¬ 
cording to the documentation and provides debugging 
services if necessary. 

HEADQUARTERS 

Westinghouse Electric Corporation 
2040 Ardmore Blvd. 

Pittsburgh PA 15221 
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OVERVIEW 

SyncSort III is a generalized disc and tape sort/merge 
system designed as a direct replacement for the IBM prod¬ 
ucts SM023 and SM-1 (5734 and 5740). It supports the 
same control cards and JCL. Unlike previous SyncSort 
releases, which were limited to 360/50 and above and 
370/155 and above, SyncSort III operates on all IBM 
Systems 360/370 under all versions of OS and OS/VS. It 
interfaces all random access devices (2314, 3330, 3330- 
11, 3340) and all tape drives (2400, 2415, 2420, 3420). 

SyncSort and its associated utilities (SyncSim, His- 
togrm) are delivered in object code on a magnetic tape. A 
simple link-edit step places the load modules in a library 
designated by the user. Default options are set via 
Superzaps. 

SyncSort is offered on either a one year license basis for 
$3,000 for the first CPU and $2,700 for each additional 
CPU or a three year license for $6,200 for the first CPU 
and $5,500 for each additional CPU. A 30-day free trial is 
available. 

There are currently more than 200 SyncSort users in 
the United States and Canada. 

DESCRIPTION 

SyncSort is a highly efficient system designed primarily 
to provide flexible sort options to IBM System/360 or 370 
OS users. It handles fixed and variable length records up 
to 32K bytes long; handles negative bias with no penalty; 
supports rotational position sensing; and offers COBOL 
and PL/1 SORT verb compatibility. 

The user can choose his own brand of efficiency with 
SyncSort. He may, for example, specify that the system 
run to minimize throughput, minimize I/O time, minimize 
CPU time, or minimize I/O accesses. In short, it’s possible 
to tailor the system to take advantage of those resources 
that are heavy while skirting those that are a little thin. 

SyncSort s efficiency is due in part to a new approach to 
sorting — for which a patent has been applied for — 
which utilizes the characteristics of random access devices 
in an optimum fashion. The vendor claims that with its 
technique, SyncSort can reduce sorting elapsed times be¬ 
tween 20 to 40 percent, while improving the performance 
of those jobs executing concurrently with the sorting 
program. 

SyncSort offers a number of other facilities, such as: 

• Efficient utilization of Disc Space without JCL 
changes. 

• Disc Space Release — excess disc space will be re¬ 
turned to the operating system at the completion of 
the data input. 

• Noncontiguous Space Allocation — Disc space can 
be utilized even though fragmented. 


• Secondary allocation — if primary space is 
exhausted, SyncSort will obtain secondary space 
allowing sorts of unexpected size to complete. 

• Alternate parm feature — provides the means to 
alter the parameters passed from a program in¬ 
voking the sort without recompiling the calling 
program. 

• Sorting of records smaller than the maximum sort 
key displacement. 

• Sorts records greater than track size (up to 32,000 
bytes). 

• Checkpoint restart for OS and VS. 

• Five optimization modes: OPT = E, minimum 
EXCP’s dynamically distributed; OPT = S, 
minimum EXCP’s equally distributed; OPT = M, 
minimum elapsed times multiprogramming environ¬ 
ment; OPT = D, minimum elapsed times in 
dedicated environment; OPT = I, minimum I/O 
time. 

• Expanded use of parameter field. 

• Detection and utilization of positive and negative 
bias. 

• Mixing of SORTWK devices (2314, 3330, 3330-11, 
3340). 

• Sort statistics incorporated into SMF. 

• Page fixing under VS to allow the sort to utilize 
EXCP-VR (the translation of CCW’s by the sort, 
dramatically reducing CPU time). 

Two other features of SyncSort are also aimed at in¬ 
creasing overall efficiency. These are SyncSim and the 
Histogrm programs. 

SyncSim is a sort simulator which calculates the 
required system resources. Based on 15 parameters that 
describe a particular configuration, it simulates the ex¬ 
ecution of SyncSort on this configuration. SyncSim then 
prints out, among other variables, the throughput time, 
CPU time, I/O time, and number of I/O accesses that 
would result in a stand-alone environment. Varying the 
parameters enables a user to determine how a change in 
the environment would affect efficiency. 

Histogrm scans a variable length file, produces a dis¬ 
tribution of the record lengths, and recommends the 
proper record segment length which will allow it to be 
handled with optimum efficiency. 

Whitlow is constantly enhancing SyncSort, and pro¬ 
jects the following enhancements for this year. 

• In-core sort. 

• Reentrant code. 

• New procedure for combining tape and disc as 
working storage. 

• VSAM support. 

Six-Step Evaluation Procedure 

A comprehensive procedure is available, free of 
charge, to assist users in evaluating the performance of 
SyncSort and relating the performance improvement to 
their sorting load. 
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• Technical presentation — a technical representative 
will provide a 2-hour presentation at the users 
facility. 

• Sort load analysis — with the use of the Sortload 
Program developed by Whitlow Computer, the users 
SMF data is analyzed and a report, summarizing the 
sorting load in elapsed time and CPU time together 
with the device utilization, is prepared. 

• Test outline — a meaningful set of tests reflecting 
the users data and environment will be outlined. 

• On-site demonstration — a Whitlow representative 
is available to assist in the execution of comparative 
bench marks. 

• Tabulation of results — a report reflecting the 
results of the bench mark will be presented to the 
user. 

PROCESSING 

Input 

Input to SyncSim is one or more data cards, each of 
which describes a possible configuration on which Sync- 
Sort will operate. The data card specifies: CPU model, 
operating system version, type of efficiency desired, core 
size, channel distribution, working device, number of 
working tracks, and amount of bias specified as a number. 

SyncSort requires that the user enter the same sort 
parameters as those required by SM-1 or SM023. The 
parameters include: amount of core available; method for 
handling messages to control listing of output; amount of 
bias (optional); devices to be used for input, output, and 
work; and the type of efficiency desired. Normally these 
parameters are specified by the user when the package is 
ordered, and they become default values if no overriding 
value is specified at execution time. 

Process 

SyncSim validates its data cards. Upon error detection, 
it prints an associated error message followed by a list of 
the card errors. Processing continues with the next data 
card. A valid card causes simulation of the sort operation 
on the specified configuration. 

SyncSort validates control cards for form and content. 
A critical error results in program termination. 

To assure the validity of a sort in process, approxi¬ 
mately 100 different checks are iteratively applied; in ad¬ 
dition, an internal trace of critical paths is in continual 
operation. An input as well as an output sequence check is 
also made to ensure that string sequence has been main¬ 
tained. If any check fails. SyncSort terminates. When a 
sort is terminated, a snap dump is taken to help determine 
the nature of the problem. 

Depending on the type of efficiency desired. SyncSort 
will modify its logic during execution to achieve it. For 


example, if reduced I/O time is the goal, SyncSort will 
evaluate possible solutions in terms of the associated I/O 
time expected. 

An interesting feature of SyncSort is the manner in 
which it treats data bias. Sorted records may be in the 
desired order, reverse order, or no order at all when it 
comes time for final sequencing. Most systems detect posi¬ 
tive bias (records are in the desired order) and produce 
longer, and thus fewer strings. This is the most efficient 
way to process. In the case of negative bias (records are in 
reverse order), many systems produce shorter strings. 
This, obviously, is less efficient as far as processing is 
concerned. 

SyncSort detects both negative and positive bias 
dynamically and produces longer strings regardless of the 
bias. Consequently, the user pays no penalty for using neg¬ 
ative bias. 

Output 

SyncSim produces a listing for each sort simulated, 
which provides the number of tracks used by sort; the 
minimum number of tracks needed by the sort; the max¬ 
imum number of records that could be sorted with the 
available tracks; the total number of EXCPs that would 
have been issued during the sort; the total amount of I/O., 
CPU, throughput, and I/O times in seconds. 

Besides the sorted file, SyncSort produces information 
messages and an optional listing of the input control 
cards. 

EVALUATION 

Judging from user response. Whitlow's claim that Sync¬ 
Sort runs faster and more economically than SM023 or 
SM-1 are well founded. Conservative estimates show 
SyncSort to be about 30 percent faster than the IBM 
utilities. 

Since we last evaluated SyncSort, the vendor has 
enhanced the system to allow it to handle records up to 
32K bytes long (formerly the upper limit was 1 3K bytes). 
Also in the works are a number of improvements to allow 
SyncSort to run more efficiently in a VS environment. 

Of particular note are the page-fix and EXCP transla¬ 
tion capabilities. Both features are aimed at increasing 
throughput by prohibiting the paging of certain pages and 
by blocking I/O interrupts. Under some conditions, how¬ 
ever. these can degrade overall performance by reducing 
service to other processing jobs. The vendor realizes this 
and has made page-fix and EXCP translation optionally 
exercised features. 

SUPPORT 

Documentation and maintenance are included in the 
license price of the package. The user receives SyncSort 
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on tape, along with two user manuals. He must install the 
package and return the tape to the vendor. Training in 
SyncSort operation is unnecessary. 

Whitlow will provide service to correct any program¬ 
ming errors in SyncSort and to maintain its compatibility 
with changes to the operating system on which it is 
running. 

HEADQUARTERS 

Whitlow Computer Systems Inc. 

222 South Marginal Rd. 

Fort Lee NJ 07024 



DIRECTORY OF SUPPLIERS 


ADL SYSTEMS INC 

10 New England Executive Park 
Burlington MA 01803 

( 617 ) 272-3400 

APPLIED DATA RESEARCH INC 

Route 206 Center 
CN-8 

Princeton NJ 08540 

( 609 ) 924-9100 

BMS COMPUTER (See Boothe 
Management Systems) 

BOOTHE MANAGEMENT SYSTEMS 

PO Box 3086 
Walnut Creek CA 94598 

( 415 ) 938-2620 

CALLDATA SYSTEMS INC 

SUBSIDIARY OF GRUMMAN DATA SYSTEMS 

20 Crossways Park North 
Woodbury NY 11797 

( 516 ) 575-3282 

COMPUTATION PLANNING 

7840 Aberdeen Rd 
Bethesda MD 20014 

( 301 ) 654-1800 

COMRESS (See Comten Inc) 

COMTEN INC 

PERFORMANCE & EVALUATION DIV 

2 Research Ct 
Rockville MD 20850 

( 301 ) 948-8000 

CUTLER-WILLIAMS INC 

2655 Villa Creek Dr 
Dallas TX 75234 

( 214 ) 243-3421 

GRUMMAN DATA SYSTEMS CORP 
(See Call Data Systems) 

GULF OIL COMPUTER SCIENCES INC 

PO Box 2100 
Houston TX 77001 

( 713 ) 228-7040 


INNOVATION DATA PROCESSING 

925 Clifton Ave 
Clifton NJ 07013 
( 201 ) 777-1940 

MARCUS POWELL ASSOCIATES 

1736 Franklin St 
Oakland CA 94612 

( 415 ) 893-7598 

OXFORD SOFTWARE CORP 

1567 Palisade Ave 
Fort Lee NJ 07024 

( 201 ) 944-0083 

PANSOPHIC SYSTEMS INC 

709 Enterprise Dr 
Oak Brook IL60521 

( 312 ) 986-6000 

PROGRAMARTCORP 

133 Mount Auburn St 
Cambridge MA 02138 

( 617 ) 661-3020 

ROCKWELL INTERNATIONAL 

INFORMATION SYSTEMS DEPT 

2201 Seal Beach Blvd 

PO Box 2515 

Seal Beach CA 90740 

( 213 ) 594-3311 

SOFTWARE DESIGN INC 

880 Mitten Rd 
Burlingame CA 94010 

( 415 ) 697-3660 

EASTERN REGIONAL OFFICE 

2460 Lemoine Ave 
Fort Lee NJ 07024 

( 201 ) 461-3130 

STANDARD DATA CORP 

1540 Broadway 
New York NY 10036 

( 212 ) 586-3100 


SUBSYSTEMS INC 

175 San Gabriel Dr 
Sunnyvale CA 94086 

( 408 ) 733-0190 


TESDATA SYSTEMS CORP 

7900 Westpark Dr 
McLean VA 22101 
( 703 ) 790-5580 

TESSERACT CORP 

Box 7658 

Rincon Annex 

San Francisco CA 94120 

( 415 ) 543-9320 


UNIVERSAL SOFTWARE INC 

136 White St 
Danbury CT 06810 

( 203 ) 792-5100 


UNIVERSITY COMPUTING CO 

7200 N. Stemmons Frwy 
Dallas TX 75247 

( 214 ) 637-5010 

VALUE COMPUTING INC 

300 VCI Bldg 
West Marlton Pike 
Cherry Hill NJ 08034 

( 609 ) 429-4200 

WEILAND COMPUTER GROUP INC, THE 

814 Commerce Dr Suite 101 
Oak Brook IL 60521 
( 312 ) 325-9300 

WESTINGHOUSE ELECTRIC CORP 

COMPUTER & INSTRUMENT DIV 

2040 Ardmore Blvd 
Pittsburgh PA 15221 

( 412 ) 256-5583 

WHITLOW COMPUTER SYSTEMS 

222 S. Marginal Rd 
Fort Lee NJ 07024 
( 201 ) 947-8500 
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Other GUIDES Available from AUERBACH 


AUERBACH Guide to Intelligent Terminals 

AUERBACH Guide to Alphanumeric Displays 

AUERBACH Guide to Communications Processing Equipment 

AUERBACH Guide to Facsimile Equipment 

AUERBACH Guide to Financial Terminal Systems 

AUERBACH Handi Guide to EDP Equipment 

AUERBACH Guide to Computer Performance Evaluation 

AUERBACH Guide to Data Base Management 

AUERBACH Guide to Microform Readers & Printers 

AUERBACH Guide to Small Business Computers 

AUERBACH Guide to Minicomputers 

AUERBACH Guide to Computing Equipment Specifications 

AUERBACH Guide to Operating Systems Enhancements 

AUERBACH Guide to Remote Batch Terminals 

AUERBACH Guide to Systems Architecture (International Edition) 


AUERBACH Publishers Inc., 


Pennsaulcen NJ 
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